> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/security-testing-orchestration/use-sto/code-repositories.md). # Code Repositories Code Repositories provides you with a repository-centric view of every code repository that Harness Security Testing Orchestration (STO) has scanned, along with the security findings inside each one. Instead of working backward from a pipeline execution to determine which repository was affected, you can start with the repository itself and drill into its findings, scan history, and remediation guidance. ## What you will learn in this topic By the end of this topic, you will be able to: * The purpose and structure of Code Repositories in STO. * The way STO decides which branch and which scan a repository row represents. * The steps to filter, sort, and search the repository list. * The steps to investigate a repository's findings, scan history, and individual findings. * The steps to set the baseline branch for a repository. *** ## Before you begin * Make sure that STO is enabled for your account, organization, and project. * Make sure that at least one repository has been scanned in the current project. A repository appears on this page only after STO ingests a scan for it. * You must have the necessary permissions to view findings. * To use the **Harness AI** sub-tab on the **Remediation** tab, Harness AI must be enabled for your account. Navigate to **Account Settings** → **Default Settings** → **Harness AI** and enable the setting. For more information, see [Fix security vulnerabilities using Harness AI](/security-testing-orchestration/use-sto/sto-remediate-issues/ai-based-remediations.md). {% hint style="info" %} Code Repositories is behind a feature flag. Contact [Harness Support](mailto:support@harness.io) to enable it for your account. {% endhint %} *** ## Understand code repositories STO models a code repository as a scan target, and each branch of that repository as a variant of that target. When a scan runs, STO records the findings against both the repository and the specific branch that was scanned. Code Repositories reads from a pre-computed summary of that data, so the list and its widgets stay responsive even when a project contains thousands of repositories and millions of findings.

Each row on the page represents one repository at one branch. STO picks that branch as follows: * If you have set a baseline branch for the repository, the row reflects the most recent scan on that baseline branch. * If you have not set a baseline branch, the row reflects the most recent scan on whichever branch was scanned last. A single pipeline execution usually runs several scans, one per scan type. The counts on a row are the aggregate across all scans in that one execution, which is why a repository can show SAST, SCA, Secret, and IaC results together. Summary counts refresh a few seconds after a scan completes, rather than within the scan itself, so a scan that finished moments ago may take a short time to appear. The following table highlights when, why, and how should you use Code Repositories in your Harness STO account: | When use it? | Why use it? | How can you leverage it? | | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | You need to know which repositories carry the most severe findings. | Pipeline-centric views show one execution at a time and make it hard to compare repositories against each other. | Sort the list by **Total findings** to rank repositories by severity weight, then open the worst offenders first. | | You are rolling out STO across a large project. | Repositories without a baseline branch do not report new-versus-existing findings correctly. | Use the **Baseline set** and **Not set** split in the **Repositories** widget to find repositories that still need a baseline. | | A developer asks why a finding was reported. | Finding detail includes the scanner, the file, the affected library, and the fixed version. | Open the finding, review the **Overview** tab, then use the **Remediation** tab to get the upgrade path and remediation steps. | *** ## Key components of the code repositories page Navigate to **Security Testing Orchestration** → **Code Repositories** to open the page. It has three parts: a row of summary widgets, a controls row, and the repository table.

#### Summary widgets The three widgets at the top summarize repository posture across every repository onboarded in the current project. The **Repositories** and **Findings by severity** widgets each carry an information icon that explains what the widget counts. The widgets display the following information: | Widget | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Repositories** | The total number of repositories in the project, followed by one count per provider that STO has ingested repositories from, displayed as a provider icon and a number. A coverage bar below splits the total into the **Baseline set** and the **Not set**. | | **Findings by severity** | The total number of findings, with the increase and decrease since the previous period shown beside it. The total is broken into **C**, **H**, **M**, and **L** counts for Critical, High, Medium, and Low. | | **Findings Trend** | A time-series chart plotting **New findings** and **Remediated** findings over the selected window, with a dated x-axis. Use the **Range** control to change the window. | {% hint style="info" %} Severity counts on this page use each finding's scanner-reported severity. Severity overrides and exemptions are not applied to these list counts. {% endhint %} #### Controls row The controls row is displayed between the widgets and the table: * **Search repositories**: Enter all or part of a repository name to narrow the list. * **Severity**: Select one or more severities to show only repositories that have at least one finding at that severity. * **+ Add filter**: Select additional attributes to filter on. Filters combine with *AND* across categories and *OR* within a category, so selecting *Critical* and *High* shows repositories that have either a *Critical* or a *High* finding. #### Repository table The table lists one row per repository. Harness allows you to sort the **Total findings** and **Last scan** columns, and the list is sorted by **Last scan** in descending order by default. The table displays the following information: | Column | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Repository** | Displays the provider icon and the repository name. | | **Branch/Variant** | Displays the branch the row represents, which is the baseline branch when one is set and the most recently scanned branch otherwise. A branch icon precedes a branch name, and a commit icon precedes a commit hash when the row represents a commit rather than a named branch. | | **Scan types** | Displays each scan type that ran in the latest execution, such as **SAST**, **SCA**, **Secret**, or **IaC**. When a row has more scan types than the column can fit, the remainder is collapsed into a **+n** chip. | | **Total findings** | Displays severity-bucketed counts displayed as **C**, **H**, **M**, and **L** labels. Sorting orders by severity weight, from *Critical* to *Low*, rather than by the label text. | | **Last scan** | Displays how long ago the latest scan completed, as a relative timestamp. | Selecting a row opens the repository detail page. The action menu at the end of each row provides per-repository actions. *** ## Investigate a repository Harness enables you to click on a list item in the repository table to view it in detail. The repository detail page has three tabs: **Overview**, **Scan History**, and **Configuration**. The branch selector at the top of the page controls which variant every tab reports on, and the header beside it shows the branch count for the repository and when it was last scanned. ### Step 1: Review the overview tab The **Overview** tab summarizes the selected branch's most recent execution.

* **Findings**: The total finding count for the execution, split into **C**, **H**, **M**, and **L**. * **Scan coverage**: The number of scan types that ran, listed by name below the count. * **Findings Trend**: A stacked bar chart of findings per execution over the selected range, with one color per issue type and a legend listing the types present, such as **External Policy**, **IaC**, **SAST**, **SCA**, and **Secret Detection**. Use **Group by** to change how the bars are broken out, the issue-type control to filter to specific types, and **Range** to change the window. The issue-type control lists only the types present in the selected range. * **Findings by Issue Type and Severity**: A color-coded matrix with one row per issue type and one column per severity, along with a **Total** column on the right and a **Total** row along the bottom. Selecting a cell opens the matching findings. * **Findings Trend by Status**: **New findings** plotted against **Remediated** findings over the selected range, with its own **Range** control. For repositories scanned by Qwiet, an SBOM summary card also appears on this tab. ### Step 2: Review scan history The **Scan History** tab lists every scan recorded against the repository, most recent first.

Filter the list by **Source**, **Branch**, **Scan type**, or **Scanner**. The **Columns** control displays how many of the available columns are currently visible, for example, *6 of 8*, and enables you to show or hide the rest. The table displays the following information: | Column | Description | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Scan ID** | Displays the scan number, with the scanner or pipeline that produced it shown below, for example, a scanner name or `_pipeline`. Selecting the scan ID opens that scan's findings. | | **Branch** | Displays the branch or commit the scan ran against. | | **Scan type** | Displays a chip per scan type in the scan, collapsed into a **+n** chip when more types run than fit the column. | | **Findings** | Displays the **C**, **H**, **M**, and **L** counts for the scan. | | **Triggered by** | Displays the identity that started the scan. | | **Started** | Displays how long ago the scan started, as a relative timestamp. | ### Step 3: Review the findings for a scan Selecting a scan ID opens a panel listing every finding in that scan. The panel header shows the scan number and its scanner, and the **Findings** tab shows the finding count.

Search by finding name, CVE, or CWE, and filter by **Severity**, **Scanner**, or **Issue Type**. Use **+ Add filter** for additional attributes, and the **Columns** control to show or hide columns from the full set, for example, *4 of 13*. The findings table displays the following information: | Column | Description | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Severity** | Displays the severity of the finding, such as **Critical** or **High**. | | **Finding** | Displays the finding name. For SCA findings, this is the package and version, such as `bson@1.0.9`. | | **Reference ID** | Displays the public identifiers for the finding, such as CVE and GHSA numbers, shown as chips. Where a finding has more identifiers than the column allows, the remainder is collapsed into a **+n** chip. | | **Scanner** | Displays the scanner that reported the finding. | Each row also has an action menu for per-finding actions. ### Step 4: Open a finding Selecting a finding opens its detail view, which has an **Overview** tab and a **Remediation** tab. The header shows the severity, the finding name, and the target repository. Use the back and forward arrows at the top of the panel to move to the previous or next finding without returning to the list.

The **Overview** tab has three collapsible sections. * **Details** describes the finding and how STO triaged it. * **Metadata** carries the identifiers and version details for the finding. * **Occurrence Raw Details** shows the unmodified scanner output for the finding as a JSON viewer with numbered, collapsible lines. Use the copy icon in the section header to copy the raw output. {% hint style="info" %} The availability of these sections may depend on the scan type. {% endhint %} ### Step 5: Review remediation guidance The **Remediation** tab provides remediation guidance from two sources, selectable as sub-tabs.

{% tabs %} {% tab title="Harness AI" %} **Harness AI** provides guidance generated by Harness AI, under the heading **AI Remediation**. The guidance is based on public information about the CVE or CWE, along with the vulnerable code snippet where the scanner captured one. {% hint style="info" %} * When generated guidance does not pass validation, the tab displays a dismissible message at the top and you can click **Regenerate** to try again. * Harness AI always returns an answer, but where no remediation exists in the model's training data the answer can be invalid. Assess a suggestion against your own target and use case before you apply it, and check the usage and license requirements of any component it tells you to install. {% endhint %} Each of the following is a collapsible section: | Section | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Vulnerability overview** | What the vulnerability is and why it matters. | | **Attack scenario** | How an attacker would exploit it, with an example payload you can copy. | | **Remediation Steps** | Numbered steps to fix the finding, including any command to run. | | **Secure coding pattern** | A code example showing the safe pattern to adopt. | | **Root cause analysis** | The underlying cause and the security principle that was violated. | | **Test cases** | Positive and negative tests, each with a description, an input, and the expected behavior. | | **Verification checklist** | Checks to confirm the fix worked. | | **Further considerations** | Additional hardening beyond the immediate fix. | | **References** | Related standards and guidance, such as the CWE entry, the relevant OWASP Top 10 category, and OWASP cheat sheets. | {% hint style="info" %} The availability of these sections may depend on the scan type. {% endhint %} Code blocks in these sections have a copy icon. Below the guidance, the panel shows when it was generated, a **Regenerate** control to produce it again. {% endtab %} {% tab title="Scanner" %} **Scanner** presents the fix that the scanner itself recommends, such as the version to upgrade a package to. {% endtab %} {% endtabs %} *** ## Set the baseline branch STO compares each scan against the repository's baseline branch to decide which findings are new. Set the baseline on the **Configuration** tab, under **Harness Settings**. Settings in this section are managed directly by Harness and are not read from the repository itself.

To set the baseline branch, complete the following steps: 1. Open the repository and select the **Configuration** tab. 2. Expand **Default branch**. 3. Under **Baseline definition**, select how to identify the baseline branch: * **Fixed Values**: A specific branch that you select and that does not change at runtime. * **RegEx**: A regular expression that is matched against branch names. Use this when the baseline branch name varies between scans. 4. Select the branch from the **Baseline branch** list. This field is required. The branch currently set as the baseline is marked in the list. 5. Click **Save** in the page header. To abandon your changes, click **Discard**. Until a baseline is set, the repository row reflects the most recently scanned branch, and new-versus-remediated reporting for that repository is based on the previous scan of the same branch. For more information, see [Set up target baselines in STO](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/set-up-baselines.md). *** ## Next steps * [Set up target baselines in STO](/security-testing-orchestration/troubleshooting-and-resources/sto-use-cases/set-up-sto-pipelines/set-up-baselines.md): Understand how baselines separate issues in your branch from issues already in the baseline. * [Fix security vulnerabilities using Harness AI](/security-testing-orchestration/use-sto/sto-remediate-issues/ai-based-remediations.md): Refine AI remediation suggestions with additional context and code snippets. * [AI-based remediations](/security-testing-orchestration/use-sto/sto-remediate-issues.md): Create pull requests and code suggestions from AI remediation advice. * [Key concepts](/security-testing-orchestration/new-to-sto/key-concepts.md): Learn about scan targets, baselines, severities, and exemptions.