Security scanning evidence
Verified pull-request controls
| Control | Verified evidence | Classification |
|---|---|---|
| Snyk pull-request check | A successful Snyk security status was recorded on the head commit of each of three recent merged pull requests reviewed | Automated security and dependency scanning evidence |
| Snyk Open Source | The authenticated Snyk configuration confirms that open-source security and licence checks are enabled for pull requests | Software-composition analysis of dependencies and licences |
| Snyk Code | The authenticated Snyk configuration confirms that code-analysis checks are enabled for pull requests, and a recent repository analysis is available | Static application security testing |
| Automated AI security review | A repository-managed review runs when a non-draft pull request is opened, reopened, or marked ready, with automatic security review enabled | AI-assisted code and security review; not a deterministic SAST replacement |
| Codex pull-request review | A recent merged pull request contains an automated Codex review with security-relevant findings | AI-assisted review evidence; review output requires human triage and verification |
| CodeRabbit review | Internal engineering records show CodeRabbit used for selected change reviews | Supplementary review evidence; automatic coverage on every pull request was not established |
| GitHub workflow | GitHub hosts the source repository, pull requests, review discussion, status checks, and workflow history | Orchestration and evidence-retention layer; GitHub is not the production application host |
What Snyk can cover
Snyk documents separate pull-request capabilities:
- Snyk Open Source performs software-composition analysis of dependencies and licences.
- Snyk Code performs source-code analysis and can provide SAST findings on pull requests when code analysis is enabled for the integrated project.
- Pull-request checks can compare the proposed branch with the target branch and report a pass or failure in GitHub according to configured thresholds.
An authenticated, read-only review of the Snyk configuration confirmed that both Open Source and Code analysis pull-request checks are enabled. Open Source checks fail only for newly introduced high- or critical-severity issues that have a fix available. Code analysis checks fail for newly introduced issues at medium severity or above. Issue-summary comments and inline Code analysis comments are also enabled.
The review did not establish that GitHub requires the Snyk status before merge. Repository-specific overrides and ignore decisions are retained with each review record.
Coverage assessment
| Requested evidence | Current position |
|---|---|
| Dependency scanning / SCA | Evidenced. Snyk Open Source is active, a recent dependency snapshot is available, and the pull-request failure conditions are documented above |
| SAST | Evidenced. Snyk Code is active, a recent repository analysis is available, and proposed changes are checked at medium severity or above. Automated AI reviews provide supplementary review |
| DAST | Open action. No authorised dynamic scan of a deployed test target, authenticated workflow, or API target has been executed |
| Secret scanning | Open action. AI review detects credential-handling risk, but no dedicated deterministic secret-scanning gate is configured |
Operating and evidence requirements
- Keep the Snyk GitHub integration enabled for all active pull requests and new commits.
- Review the enabled Open Source and Snyk Code pull-request checks at least annually and after material integration changes.
- Define issue-ignore approval, expiry, repository-specific overrides, and required-check enforcement.
- Retain the scan status, summary, reviewed commit, findings, disposition, and remediation link.
- Rerun checks after material pull-request updates; the repository-managed AI workflow does not currently trigger on every synchronisation event.
- Treat AI review as supplementary expert review, not proof of complete source-code coverage.
- Establish DAST only against an authorised test target with written scope, permitted domains and addresses, test accounts, safety restrictions, monitoring, and a stop contact.
- Track confirmed findings through remediation and independent or controlled retest.
Pull-request decision pipeline
| Stage | Input | Decision | Evidence retained |
|---|---|---|---|
| Change admission | Pull-request revision and target branch | Draft changes remain reviewable; non-draft changes enter automated review | Pull request, revision, author, and target |
| Dependency analysis | Proposed dependency and manifest changes | Newly introduced fixable high or critical open-source issues fail the configured Snyk condition | Scan status, issue class, introduced dependency, and remediation decision |
| Static code analysis | Proposed source changes and supported repository content | Newly introduced medium-or-higher Snyk Code findings fail the configured condition | Scan status, rule, affected change, severity, and disposition |
| AI-assisted review | Source diff and repository context | Security-relevant design, authorization, validation, and secret-handling observations are triaged by a human | Review comment, response, correction, or documented rejection |
| Human review | Business intent, diff, generated evidence, and automated results | Reviewer confirms correctness, unresolved risk, and scope before approval | Reviewer identity, approval state, and unresolved discussion |
| Merge gate | Latest revision and configured required checks | Required-check enforcement is not verified; the intended gate accepts only the latest approved and passing revision | Protected-branch decision and merged revision |
Finding disposition rules
An automated result is linked to the exact revision. A result is classified as validated, false-positive, accepted risk, remediated, or superseded. False-positive and risk-acceptance decisions include technical rationale, approver, compensating control, expiry, and re-review trigger. A later successful scan does not close a previously validated finding unless the exact condition is removed and the relevant regression path is verified.
Open-source and static-analysis findings remain separate evidence streams because a clean dependency result does not establish source-code security and a clean SAST result does not establish dependency integrity, dynamic behavior, provider configuration, secrets history, or authorization correctness.
Current limitations
- Branch-protection evidence was unavailable, so successful status checks are not represented as mandatory merge gates.
- The repository does not retain a supported dependency lockfile, reducing reproducibility and the precision available to dependency analysis.
- Current Snyk results contain open findings that require remediation and tracking. Counts, issue details, and private project identifiers are intentionally excluded from this public document.
- Code analysis does not currently cover every source file. Unanalysed portions remain a coverage gap. The remediation register requires identification and reduction of unsupported or excluded paths.
- No baseline vulnerability report, issue-ignore list, DAST report, or dedicated secret-scanner report was available for this public evidence set.
- Tool availability and a passing check do not establish that the repository is vulnerability-free.