SA-5(5): Source Code

SA-5(5) (Source Code) requires you to manage source code as a controlled, reviewable supply chain input: define how you receive it, verify its integrity and licensing, restrict access, and retain proof that source code used in your system is authorized and traceable. Operationalize it with a source code governance runbook, repository controls, and auditable evidence. ¹

Key takeaways:

• Treat source code (including third-party and open-source) as a governed asset with defined intake, approval, and traceability steps.
• Make repository controls auditable: access, branch protections, required reviews, and build provenance should be easy to evidence.
• Evidence wins audits: keep a repeatable “minimum evidence bundle” per release that proves what code shipped and who approved it.

SA-5(5): Source Code sits in the System and Services Acquisition (SA) family, so auditors and customers will read it as a “how do you prevent untrusted or unmanaged code from entering your environment” requirement. The practical risk is simple: if you cannot prove what code was introduced, who approved it, and where it came from, you cannot credibly manage software supply chain exposure or respond cleanly to an incident.

For a CCO, GRC lead, or Compliance Officer, the fastest path is to convert SA-5(5) into a requirement-level runbook tied to your SDLC and third-party due diligence motions. You want crisp governance around (1) where source code is allowed to live, (2) who can access and change it, (3) what checks are required before code merges and releases, and (4) what evidence you retain for each release. This page gives you an operator’s view: applicability, step-by-step execution, what artifacts to keep, common audit traps, and an execution plan you can assign to Engineering with clear acceptance criteria. ²

Regulatory text

Control: “NIST SP 800-53 control SA-5.5.” ¹

Operator interpretation of what this means: The enhancement title (“Source Code”) signals that your program must specifically address source code as an acquisition and security governance object, not just “software” generally. In practice, you are expected to establish and operate controls that ensure source code used to build, deploy, or operate the system is:

• Authorized (you have the right to use it, and it’s approved for the system),
• Traceable (you can identify provenance, version, and change history),
• Protected (access is controlled; changes are reviewed and logged),
• Verifiable (you can show the checks and approvals that allowed it into production),
• Auditable (you retain evidence that demonstrates ongoing operation).
  ²

Because the provided excerpt is short, auditors typically evaluate SA-5(5) by inspecting your SDLC controls and asking for proof that third-party and open-source code is governed the same way as first-party code, with explicit intake and approval paths. ²

Plain-English requirement (what you must accomplish)

You must be able to answer, with evidence:

1. What source code is in production?
2. Where did it come from (internal team, third party, open source, acquired code)?
3. Who approved it and under what rules?
4. How do you prevent unauthorized or unreviewed changes?
5. Can you reproduce the build and show the exact commit(s) that shipped?

If you can produce those answers quickly for a sampled release, you are operating SA-5(5) in a way that stands up to assessments.

Who it applies to (entity + operational context)

Applies to:

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 Rev. 5 controls. ¹

Operationally, it touches:

• Application engineering teams (developers, maintainers)
• Platform/DevOps (CI/CD, artifact repos)
• Security engineering (code scanning, supply chain controls)
• Procurement / third-party risk (software providers, consultants delivering code)
• Legal/commercial (licenses for third-party and open-source code)

Scope decisions you should lock early (and document):

• “Source code” includes: application code, infrastructure-as-code, build scripts, pipeline definitions, and code delivered by third parties (consultants, integrators, outsourced dev).
• Decide whether you also treat “configuration as code” and policy-as-code as in scope; most teams do, because it can materially change system behavior.

What you actually need to do (step-by-step)

1) Publish a SA-5(5) control card (make ownership and triggers explicit)

Create a one-page control card that engineering can run without translating compliance language.

Minimum fields (practical and auditable):

• Objective: Only authorized, reviewed, and traceable source code enters production.
• Owner: Engineering (primary), Security (oversight), GRC (evidence + testing).
• In-scope systems: name the system boundary or product(s).
• Trigger events: new repository, new third-party code intake, new dependency policy, each release, emergency patch.
• Execution steps: see below.
• Exceptions: break-glass flow and retroactive review requirements.
  ¹

2) Standardize where code lives (repository governance)

Set a hard rule: production code must reside in approved version control orgs/workspaces.

Implement:

• Central VCS (Git-based) with enforced SSO/MFA.
• Repository creation standards (naming, owners, default branch rules).
• Mandatory logging and retention of commit history and PR review metadata.

Evidence target: you can show auditors that “production code cannot be maintained in personal accounts or unmanaged repos” and prove it with settings exports and access lists.

3) Lock down access (least privilege + separation of duties)

Define roles and enforce them:

• Read for most staff
• Write limited to contributors
• Admin restricted; require a ticket for elevation
• Protect sensitive repos (crypto, auth, billing, data pipelines) with tighter access

Add operational rules:

• Quarterly (or change-driven) access recertification for code orgs, critical repos, and CI/CD admins (your cadence can be risk-based; document it).
• Immediate deprovisioning on termination and role change.

4) Enforce change control at the code level (PR requirements)

Controls that map cleanly to SA-5(5) testing:

• Branch protection on default branch
• Required pull request reviews (set a minimum reviewer rule appropriate to risk)
• Require status checks to pass (tests, SAST, dependency scan, secrets scan)
• Disallow force-pushes to protected branches
• Require signed commits where feasible, or document an alternative integrity approach

Auditor-friendly acceptance criteria: “No direct commits to main; every change has an approver and automated checks.”

5) Govern third-party and open-source code intake (TPDD meets SDLC)

Treat any non-employee provided code as third-party intake:

• Consultants delivering code: require delivery through your repos, under your access model, with PR-based review.
• Third-party libraries/open source: enforce an allow/deny policy and keep a record of approvals for exceptions.
• License review workflow: define who approves high-risk or incompatible licenses and how decisions are recorded.

This is where many programs fail: third-party risk questionnaires exist, but code arrives via zip files, email, or unmanaged repos. SA-5(5) expects disciplined intake.

6) Make releases traceable (build provenance and “what shipped” proof)

For each release, retain a release record that links:

• Release tag/version
• Git commit SHA(s)
• Build job ID and logs
• Artifact digest/hash in artifact repository
• Deployment record (change ticket or pipeline run)

Your goal is to recreate the chain from source to deployed artifact without detective work.

7) Run control health checks and remediate

Set a recurring check (owned by Security/GRC with Engineering support):

• Sample repos and confirm branch protections, required reviews, and scan gates
• Sample releases and confirm traceability artifacts exist
• Track gaps as remediation items with due dates and closure evidence
  ¹

Required evidence and artifacts to retain (minimum evidence bundle)

Use this as your audit binder checklist:

Governance

• SA-5(5) control card (owner, triggers, steps, exceptions)
• Source code management standard (what repos are approved; what “in production” means)
• Third-party code intake procedure (consultants, acquisitions, OSS policy)

Repository controls

• Screenshots/exports of branch protection rules for sampled repos
• PR review settings and examples (show reviewer, approval, checks passed)
• Access lists for code orgs and critical repos (and recertification evidence)

Intake and approval

• Approved dependency policy and exception approvals
• Records of license/security review decisions for exceptions

Release traceability

• Release notes tying version to commit SHA(s)
• CI/CD pipeline logs showing build from those commits
• Artifact repository entry with digest/hash
• Deployment record tied to artifact

Control operation

• Health check results, tickets, and validated closure notes
  ¹

Common exam/audit questions and hangups

Auditors and customer assessors tend to ask:

• “Show me a production repo. Can a developer push directly to main?”
• “Pick a release from last quarter. Prove what commit shipped and who approved it.”
• “How do you control code written by third parties or contractors?”
• “How do you prevent secrets from entering source control, and what happens if they do?”
• “Where is the evidence stored, and how long do you retain it?”

Hangups you can preempt:

• Evidence spread across tools with no release-level linkage.
• “We do peer review” stated in policy, but branch protections allow bypass.
• Contractors committing via shared accounts or unmanaged repos.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance

• Fix: implement enforceable repo settings and keep exports/screenshots as evidence.

2. Treating open source as “just dependencies”

• Fix: define an approval and exception path; keep decision records.

3. No clean traceability from code to artifact

• Fix: require release tagging and artifact digests tied to CI runs.

4. Break-glass with no retroactive governance

• Fix: define an emergency path that requires post-merge review and documented approval within a defined internal SLA (your choice; write it down and follow it).

5. Third-party code bypass

• Fix: require third-party contributors to use your repos, your PR workflow, and your identity controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Risk framing you can use internally (non-numeric, audit-focused):

• Source code weaknesses become incident response weaknesses. If you cannot prove what changed, you will struggle to scope impact and restore safely.
• Supply chain exposure increases when code intake paths are informal, especially for third-party deliverables and open-source exceptions.
• Assessment risk is high when controls exist “in principle” but are not enforced in tooling, or when evidence is not retained in a consistent bundle. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define “done”)

• Assign owners and publish the SA-5(5) control card (objective, triggers, exceptions). ¹
• Inventory production repos and map them to in-scope systems.
• Set baseline repo controls for critical repos: branch protection, required PR reviews, required status checks.
• Define the minimum evidence bundle for releases and choose a single retention location (GRC repository, ticketing system, or compliance evidence folder). ¹

Days 31–60 (enforce intake + traceability)

• Implement third-party code intake rules: no emailed zip files; all code arrives via controlled repos and PRs.
• Publish dependency/OSS approval workflow and exception handling.
• Connect CI/CD outputs to artifact repository with digests; standardize release tagging.
• Pilot an audit drill: pick one recent release and produce the full evidence bundle within a short internal timeframe.

Days 61–90 (operate and prove sustained control)

• Run the first formal control health check and track remediation to closure. ¹
• Add access recertification for code orgs and CI/CD admin roles.
• Expand branch protections and scan gates to all in-scope repos.
• Formalize reporting: monthly control status, open exceptions, and overdue remediation.

Where Daydream fits naturally: Daydream helps you turn SA-5(5) into an assignable control card, define the minimum evidence bundle per release, and run recurring health checks with remediation tracking so you can answer audits without scrambling. ¹

Frequently Asked Questions

Does SA-5(5) apply only to internally written code?

Treat it as applying to any source code that affects your system, including third-party delivered code and open-source components that become part of your deployed software. Your auditors will test whether non-employee code follows the same governance path. ²

What is the fastest audit-ready proof that SA-5(5) is working?

Produce a sampled release package showing commit SHA(s), PR approvals, required checks passing, CI build logs, artifact digest, and deployment record. Auditors care less about narratives and more about traceable evidence.

We allow emergency fixes. Will that fail SA-5(5)?

Emergency paths are acceptable if they are controlled: restricted permissions, documented approval, and a required post-change review with recorded evidence. Write the exception rule and prove it ran.

How do I handle consultants who want to develop in their own repositories?

Treat that as a third-party intake risk. Require development in your controlled repos or require mirroring into your repos with full PR history and approvals before any production merge.

Do we need signed commits for SA-5(5)?

Signed commits are a strong integrity control, but assessments often accept other integrity mechanisms if they are enforced and evidenced (protected branches, required reviews, CI gates, restricted admins). Document your standard and your rationale.

Where do teams usually lose evidence?

Release traceability. PR approvals live in Git, builds live in CI, artifacts live in another system, and deployments live elsewhere. Fix this with a standardized “release evidence bundle” that links across tools. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5