> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md).

# Assessments

The portfolio view and the per-application assessment — target levels, what the score counts, and why Heeler refuses to call an unscanned thing clean.

**Standards** in the navigation is the portfolio view: every application, measured against [ASVS](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/owasp-asvs.md).

<figure><img src="https://414480750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FXP3dp2kecwKA2KvYkntz%2Fuploads%2Fgit-blob-ad24d6121e142134aee69cc55bde41f22739d74b%2Fsc-standards-list.png?alt=media" alt="The Standards portfolio view listing nine scopes, each with its domains, target level, a score showing automated-signal and manual-verification counts, a violated count, and when it was computed."><figcaption><p>Standards — one row per scope, with the split between what Heeler verified and what still needs a person.</p></figcaption></figure>

| Column           | What it shows                                                                                                                            |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Application**  | The scope. Opens that application's [Standards tab](/mrecEO40m5D6bt7Pq5pE/catalog/applications/application-detail.md#standards).         |
| **Domains**      | The [domains](/mrecEO40m5D6bt7Pq5pE/catalog/domains.md) it belongs to. Filter the list by domain to review one part of the business.     |
| **Target level** | The level this application is measured against — see below.                                                                              |
| **Score**        | Two numbers and a bar: how many requirements Heeler **verified from an automated signal**, and how many **require manual verification**. |
| **Violated**     | Requirements Heeler can see are *not* met.                                                                                               |
| **Computed**     | When the assessment last ran.                                                                                                            |

{% hint style="info" %}
**Unassigned repositories** is a scope too. Repositories not mapped to any application are assessed as one bucket, so nothing falls out of the picture — but it is a placeholder, not a real unit of ownership. [Map them to applications](/mrecEO40m5D6bt7Pq5pE/get-started/map-your-organization/applications.md) and they move into the scope that means something.
{% endhint %}

## The target level

Every application is assessed at all three levels. The **target** is the one it is held to, and it comes from the application's **tier**:

| Application tier                       | Target level |
| -------------------------------------- | ------------ |
| Tier 1 · Tier 2                        | **L2**       |
| Tier 3 · Tier 4                        | **L1**       |
| No application (the unassigned bucket) | **L1**       |

Set a level explicitly on the application's Standards tab to override that. Otherwise the tier decides — which means **retiering an application re-targets its assessment**, and that is the intended behaviour: assurance should follow criticality.

## Verified, violated, and manual

This is the part worth understanding before you read a score. Each requirement lands in one of five states:

| Status             | Means                                                                   |
| ------------------ | ----------------------------------------------------------------------- |
| **Verified**       | Heeler has positive evidence the requirement is met.                    |
| **Violated**       | Heeler has evidence it is **not** met.                                  |
| **Partial**        | Met in some of the scope, not all of it.                                |
| **Manual**         | Heeler has no automated signal for this requirement. It needs a person. |
| **Not applicable** | Out of scope for this application.                                      |

The large **Manual** count on a fresh assessment is not a gap in the product. Most of ASVS asks about things no scanner can observe — whether your session timeout is appropriate, whether your business logic enforces the right authorization. Heeler marks those honestly rather than guessing.

### Absence of evidence is not evidence

The rule underneath the whole assessment: **Heeler will not call something verified because it failed to find a problem.**

A repository that has never been scanned has no findings. A manifest that was never resolved has no vulnerable dependencies. Read naively, both look clean — and an assessment built that way would award its highest scores to the code nobody has looked at.

So coverage is required before a clean result counts:

* A code root with no attesting scan on its branch is **uncovered**, not verified.
* Dependencies that were never resolved produce no advisories, and that is not a pass.
* An endpoint whose authentication Heeler cannot see is neither a breach nor clean — *auth we cannot see is auth we do not credit*.
* A Scorecard check that did not run reads as uncovered, not as failed.

The practical consequence: **improving your coverage will change your score**, sometimes downward, because newly scanned code can reveal violations that were previously invisible. That is the assessment becoming more truthful, not worse.

## What Heeler can verify automatically

Nine kinds of evidence back the automated half of an assessment:

| Evidence                                                                         | Measured per                        |
| -------------------------------------------------------------------------------- | ----------------------------------- |
| **SAST findings**                                                                | Code root                           |
| **Dependency vulnerabilities**                                                   | Code root                           |
| **Secrets** — credentials outside a managed store, in the repository or in CI/CD | Repository                          |
| **Endpoint authentication**                                                      | Discovered endpoint                 |
| **Runtime exposure**                                                             | Discovered endpoint                 |
| **CI/CD configuration posture**                                                  | Repository                          |
| **SBOM generation**                                                              | Code root                           |
| **OpenSSF Scorecard checks**                                                     | Repository                          |
| **An enforced guardrail**                                                        | Repository in the guardrail's scope |

The last one is how a *practice* becomes evidence. Some requirements ask for a documented control rather than an observable property; a guardrail that blocks the pull request is the enforced expression of that control, so an enabled guardrail with a matching rule counts as evidence for the repositories in its scope. That is exactly what [guardrail bundles](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md) are for.

## Reading one application

An application's **Standards** tab is the requirement-by-requirement view — level cards, a **Chapters** breakdown, and the full requirements table with each one's status and evidence count.

{% content-ref url="/pages/YXs2bd38fdTQ0JOYxOuy" %}
[Application Detail](/mrecEO40m5D6bt7Pq5pE/catalog/applications/application-detail.md)
{% endcontent-ref %}

The **Assessed** toggle there takes an application out of the assessment without deleting anything — turn it back on and its history is intact.

## Keeping it current

Assessments are recomputed by Heeler; the **Computed** timestamp on every view tells you how fresh the one you are reading is. Applying a [guardrail bundle](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md) changes scores at the next recompute rather than immediately, and the bundle dialog says so.

## Related

* [OWASP ASVS](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/owasp-asvs.md) — the standard, its levels and chapters.
* [Guardrail Bundles](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md) — turning a level into enforcement.
* [Compliance Reports](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/compliance-reports.md) — the assessment as a document.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.