Agentic SDLC Security Audit Add-On

The Security Audit add-on extends Agentic SDLC with a weekly automated security scan. Each Monday at 04:00 UTC, OSC clones your app's source code, runs a set of deterministic security scanners, and converts each new finding into a standard SDLC ticket. The ticket then flows through the same triage, approve, implement, and merge pipeline as any request you file manually.

The add-on is opt-in, per-app, and requires the base Agentic SDLC feature to be enabled first.

Prerequisites

  • An OSC account on a paid plan (Personal, Professional, or Business)
  • Agentic SDLC enabled and in Active status for the app
  • The same git token you provided when enabling Agentic SDLC (the scanner uses it to clone the repository)

Enable from My Apps

  1. Go to My Apps and click the app you want to enable the add-on for.
  2. In the detail panel, open the Settings tab.
  3. Find the Security Audit toggle and turn it on.
  4. The toggle switches to Active. The first scan will run at the next Monday 04:00 UTC slot.

If the base Agentic SDLC is not yet active, the toggle is disabled and shows "Enable Agentic SDLC first". Enable and bootstrap the base feature before returning here.

What the Scanner Checks

Each weekly run performs four passes against the cloned repository. The scanner auto-detects the language in use from manifest files in the repo root.

Pass Tool What it finds
Dependency CVEs npm audit (Node), pip-audit (Python), govulncheck (Go), cargo audit (Rust) Known CVEs in direct and transitive dependencies
Secret scan trufflehog (verified matches only) API keys, tokens, or credentials committed to the repo. Unverified pattern matches are suppressed to reduce noise.
Dockerfile advisory hadolint Errors and warnings in Dockerfile or Dockerfile.osc. Style-level hints are suppressed.
Base image freshness Registry manifest comparison Flags base images whose tag digest has drifted from the registry's current digest and is more than 30 days stale

What is not scanned in V1

The first version focuses on findings that non-developer app owners can act on without specialist knowledge. The following are out of scope for now: SAST (Semgrep, CodeQL), infrastructure-as-code scanning, container-runtime vulnerability scanning (Trivy), licence compliance, and SCA provenance checks.

How Findings Become Tickets

After the scan completes, OSC posts the findings to the Agentic SDLC pipeline. For each finding:

  1. OSC checks whether an open ticket for the same finding already exists (see Deduplication below).
  2. If no matching ticket exists, a new ticket is created in your app's Gitea repository with:
  3. Label sdlc/source:security-audit — marks it as scanner-produced
  4. Label sdlc/status:triage — enters the normal triage queue, identical to a user-filed request
  5. Label app:{appId} — scopes it to your app
  6. The triage agent picks up the ticket, analyses the finding, and posts an implementation plan.
  7. You review the plan in the Requests tab of your app's detail panel, then approve, revise, or cancel it.
  8. If approved, implementation agents open a pull request and the fix flows through the standard review and merge path.

The scanner never opens pull requests or makes commits directly.

Deduplication

The same vulnerability or advisory will not produce a new ticket every week. OSC stores a fingerprint (derived from the rule ID, affected package, and version) in the ticket body. Before creating a new ticket, OSC checks all open tickets labelled sdlc/source:security-audit for that app. If the fingerprint already exists in an open ticket, the finding is skipped.

Resolved findings (tickets that were closed after a fix was merged) will re-open as new tickets in a future scan only if the underlying issue is still present in the code.

Schedule

The security audit runs weekly, every Monday at 04:00 UTC. This is three hours before the Agentic SDLC base feature's weekly self-improvement run (09:00 UTC on Mondays), so the two tasks do not compete for resources.

The Settings tab shows the timestamp of the last completed scan and the scheduled time of the next run.

Safety Rails

The Security Audit add-on inherits all the safety mechanisms of the base Agentic SDLC feature.

  • Circuit breaker: If your app's circuit breaker is open (for example, because consecutive agent runs failed), the scan will not create new tickets until you clear the circuit breaker and re-enable the pipeline.
  • Monthly run cap: Security audit sub-tasks count toward the same monthly implementation-run cap as user-filed tickets.
  • Triage and approve gate: Every finding requires your explicit approval before any implementation work begins. No finding is ever auto-approved regardless of severity.

Disable

To stop the weekly scan, return to the Settings tab of your app's detail panel and toggle Security Audit off.

Disabling the add-on removes the weekly scan task. Any open security tickets in Gitea are not deleted; they remain for you to close or continue acting on manually. The base Agentic SDLC feature continues to run normally.

Disabling the base Agentic SDLC feature automatically disables the Security Audit add-on at the same time.

Gitea Label Reference

The following label is added to your app's Gitea repository when the Security Audit add-on is first enabled:

Label Meaning
sdlc/source:security-audit The ticket was created by the automated scanner, not filed manually. Used for deduplication and for filtering security-related tickets in the Requests view.

Frequently Asked Questions

The scan ran but no tickets appeared. Why?

Either no findings were detected (the scan was clean), or all findings matched existing open tickets and were deduplicated. The Settings tab shows the last scan timestamp and the number of tickets created and deduped.

I have a Dockerfile but no language manifest file. Will the scanner still run?

Yes. The Dockerfile advisory and base image freshness passes run regardless of language. The dependency CVE pass requires a manifest file (package.json, requirements.txt, go.mod, or Cargo.toml) and is skipped when none is found.

Can I trigger a scan before Monday?

Not in V1. Scans run on the fixed weekly schedule. If you want to address a known vulnerability immediately, file a manual request in the Requests tab instead.

My repo uses a language not listed above. What happens?

The dependency CVE pass is skipped for unsupported languages; the other three passes (secret scan, Dockerfile advisory, base image freshness) still run. Coverage for additional languages can be added in future releases.