> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sreagent.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Find vulnerable dependencies and download an SBOM

> See which packages your repositories pin, which of them have known vulnerabilities, and download a CycloneDX SBOM of a repository or a service.

SRE Agent reads the lockfiles of your connected repositories once a week, matches the packages they pin against public security advisories, and files each match as a finding in the [Security queue](https://docs.sreagent.app/guides/security-cost/security.md). The **Dependencies** tab shows what was read and what was found, and lets members download an SBOM.

Business plan

Dependency scanning is part of the infrastructure suite and of [weekly code detection](https://docs.sreagent.app/guides/fix/code-improvement.md#cover-every-repository). It needs weekly code detection switched on and the GitHub App connected. Nothing about your repositories is sent to the advisory source: the advisories are downloaded as public files and the matching happens on SRE Agent.

## What is read

| Ecosystem | Files |
| - | - |
| npm | `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock`, `pnpm-lock.yaml` |
| Python | `poetry.lock`, `uv.lock`, `pdm.lock`, `Pipfile.lock`, `requirements*.txt` |
| Go | `go.mod` |
| Hex | `mix.lock` |
| Ruby | `Gemfile.lock` |
| Rust | `Cargo.lock` |
| Java and Kotlin | `gradle.lockfile`, `gradle/libs.versions.toml`, `pom.xml` |
| PHP | `composer.lock` |

Files are found at any depth, outside vendored folders such as `node_modules`. Up to 64 files per repository are read, each up to 16 MB. A repository over the size the weekly scan reads is shown as **not read: the repository is over the size read here**, never as clean.

## What a finding says

A finding names the advisory, the package and version, the versions that fix it, and where it was found. Its severity comes from the advisory's CVSS score, or its severity word when it has no score. A package that is only a development dependency is filed one severity lower, down to low. A bump from one vulnerable version to another is the same finding, and a version that is no longer affected resolves it on the next complete read.

Findings have the same states, assignee, due date and risk acceptance as every other finding. Fixing one means upgrading the package; pull requests that do it are not part of this release.

## Honest about what was not read

The tab never shows a file as clean when it could not be read completely. Each file has a status:

| Status | Meaning |
| - | - |
| **parsed** | Read completely. |
| **partial** | Read, with a reason: a requirement that is not pinned to one version, a Maven `pom.xml` (it lists declared versions, not installed ones), versions that could not be compared, or more than 50,000 packages in one file. |
| **unpinned** | A requirements file with no pinned line. |
| **too large to parse** | The file was too large or too complex to read within the limits. A very large pnpm lockfile (tens of thousands of packages) can end here. |
| **not read** | Left out, for example because it was over 16 MB. |
| **failed** | The file was not in the format its name says. |

A file that is not read completely never marks a finding as fixed.

## Keeping it current

* **New advisories.** Advisories are refreshed every day. When a package you use gets a new advisory, your stored packages are matched again, without waiting for the next weekly scan. The **Advisories as of** list at the bottom of the tab shows the date for each ecosystem. If an ecosystem was last updated more than 72 hours ago, the Dependencies area of the Overview is marked stale.
* **Pushed lockfiles.** A push to a repository's default branch that changes a lockfile reads that file again, so a merged fix shows as fixed within minutes. This needs the GitHub App to receive push events, which the GitHub App does by default.

## Organizations that read a parent's GitHub connection

A child organization that reads its parent organization's GitHub connection has no scan of its own. The parent's weekly scan reads the repositories, so their dependency findings and credential findings appear in the parent organization and not in the child. The child's Dependencies tab says so. Allow rules made in the child do not apply to the parent's scan.

## Download an SBOM

Members can download a [CycloneDX](https://cyclonedx.org/) 1.5 SBOM from the **Dependencies** tab with **Download SBOM** beside a repository or a service. A service's SBOM is the union of its code repositories. You can also ask for one over MCP with `get_sbom`.

An SBOM lists every package the lockfiles pin, with its package URL and whether it is a development dependency, the dependency graph where the lockfile has one, and the open findings as vulnerabilities. Your triage is exported as VEX analysis: a false positive is **not affected**, an accepted risk is **exploitable** with no fix planned and your reason, and a finding being fixed is **in triage**. The document says it was read from lockfiles at a commit. It is an inventory, not an attestation and not a build-time SBOM.

Each download is recorded in the audit log, and a person can download 20 an hour, shared between the page and MCP. A document over 20 MB is not offered as a file; download the SBOM of each repository instead.

## Credentials committed to repositories

The same weekly scan reads every text file of your repositories for credentials: cloud keys, tokens, private keys, JSON web tokens, API keys and passwords in URLs. A finding keeps the kind of credential, the file and line, a prefix of at most four characters and a hash of the value, and never the value. It appears on the **Secrets** tab and in the queue. A finding on the same line as a hardcoded secret found by the code scan is shown as one row with **2 places**.

Placeholders such as `changeme`, and matches in `test/fixtures`, `examples` and `docs` folders or in `*.example` files, are filed as low. A generic match must clear an entropy check, so a value made of one repeated character is not reported. At most 200 findings per repository per scan are filed, and 2,000 open per organization.

### Allow rules

An org admin can tell the scan that some matches are known and safe. Open **Security**, then **Settings**, and add a rule under **Secret allow rules**:

1. Enter a **Path pattern**. `**` matches any run of characters including `/`, `*` matches any run without `/`, and `?` matches one character. For example `vendor/**` or `**/fixtures/*.pem`.
2. Optionally enter a repository (`owner/name`) and a kind of credential. Blank means every repository and every kind.
3. Write why it is safe, 10 to 500 characters, without quoting the credential. Optionally set an expiry date.

The scan then files nothing for matches the rule covers. A rule closes nothing that is already filed: mark those findings false positive from the **Findings** tab. You can keep up to 100 rules, and manage them over MCP (`list_secret_allow_rules`, `create_secret_allow_rule`, `delete_secret_allow_rule`) or the configuration API.

## Related

* [Review security findings](https://docs.sreagent.app/guides/security-cost/security.md): the queue, states and the digest.
* [Find recurring bad behaviour with the code scan](https://docs.sreagent.app/guides/fix/code-improvement.md): weekly code detection.
* [MCP reference](https://docs.sreagent.app/api-reference/mcp.md): the tools named above.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.