SECURE SOFTWARE DEVELOPMENT AND APPLICATION SECURITY STANDARD

Secure SDLC · Code Review Gates · SAST/DAST/SCA · Secrets · Dependencies and SBOM · Pipeline Security

Table of Contents

1. Purpose and Scope
2. Principles
3. The Secure SDLC
4. Security Gates
5. Code Review Requirements
6. Automated Security Testing: SAST, DAST, SCA
7. Secrets in Code
8. Dependencies and Software Bill of Materials
9. Pipeline and Build Security
10. Infrastructure as Code
11. Vulnerability Handling for Software
12. Roles and Responsibilities
13. Regulatory and Framework Alignment Summary
14. Document Control

1. Purpose and Scope

The Cyber Engineering pillar exists to build securely. Its mission statement, set in CERG-GOV-FRM-001, is “build securely, deploy confidently, consult continuously.” Until this standard, the program had no document that said what building securely actually requires. The architecture review procedure CERG-PRC-AR-001 governs the engagement; this standard governs the code.

This standard establishes the requirements for secure software development across the CERG-managed estate: how software moves through a secure development lifecycle, the security gates it passes, the code review and automated testing it is subject to, how secrets and dependencies are handled, and how the build pipeline that produces it is itself secured.

It applies to every piece of software CERG-managed teams write or materially modify: customer-facing and internal applications, microservices and APIs, scripts and automation, integration and glue code, and infrastructure-as-code. It does not govern the security of purchased software, which is handled by CERG-PRC-TPRM-001, except where purchased components are embedded as dependencies (Section 8).

The Standard Is a Floor, Applied by Risk Tier

Not every script needs a penetration test. This standard sets the minimum bar for all software and then scales the rigor by the risk tier of what is being built. A throwaway internal report generator and an internet-facing application that processes regulated data are both in scope; they are not subject to the same gate intensity. Section 3.2 defines the tiers. The floor is never zero, and it is never optional.

2. Principles

Six principles govern secure development in CERG.

1. Shift left, but do not shift blind. Security findings are cheapest to fix before code is written and most expensive after release. Testing, review, and threat modeling happen as early as the lifecycle allows. But early testing that no one acts on is theater; every gate has an owner and a consequence.
2. The pipeline is the enforcement point. A requirement that depends on a developer remembering it will be forgotten. Security requirements are enforced by the build pipeline wherever a machine can enforce them. Human review is reserved for what a machine cannot judge.
3. Build securely; do not own the result. Consistent with the Engineering pillar mission, Engineering builds software securely and hands it off. Engineering does not become the permanent operator of every application it helps build. Security posture travels with the handoff.
4. A finding is a risk until it is closed or accepted. An open security finding is not a backlog item that quietly ages out. It is closed, or it is risk-accepted through CERG-PRC-RM-001. There is no third option.
5. Provenance is part of the product. Software that cannot be traced to its source, its dependencies, and its build is not trusted. Every release carries a Software Bill of Materials and a verifiable build provenance.
6. Secrets never live in code. This principle is absolute and has no risk-tier exception. Section 7.

3. The Secure SDLC

3.1 Lifecycle Phases

Secure development is not a phase bolted onto delivery. Security activity is defined for every phase of the lifecycle.

3.2 Software Risk Tiers

The intensity of the gates in Section 4 scales by software risk tier. The tier is assigned at requirements and confirmed at design review.

Tier Is Assigned, Not Assumed

A team does not get to call its own software Tier 3 to avoid the gates. The tier is proposed by the building team and confirmed by the Application Security Engineer at design review. When in doubt, the higher tier applies. Disagreements are resolved by the Engineering Pillar Leader, and a tier decision that lowers rigor is recorded.

4. Security Gates

A security gate is a checkpoint software must clear to advance. Gates are enforced by the pipeline (Section 9) wherever automatable.

4.1 The Gate Set

4.2 Gate Bypass

A gate is bypassed only through a risk exception filed under CERG-PRC-RM-001. The exception names the gate, the reason, the compensating control, and an expiry. A bypassed gate without a filed exception is a control failure, and the build is not released. The secrets-scan gate is the one gate that is never bypassed.

5. Code Review Requirements

1. Every change to a protected branch is reviewed. No change reaches a release branch without at least one approving review from someone other than the author. Tier 1 software requires two approving reviewers.
2. The reviewer is competent in the change. A review approval asserts the reviewer understood the change and saw no security defect. An approval given without reading the change is a falsified control.
3. Author cannot self-approve. The person who wrote the change cannot be a required approver of it. This holds even on a small team; if only one other person can review, that person reviews.
4. Security-sensitive changes pull in Application Security. Changes to authentication, authorization, cryptography, input handling, or data export require an Application Security Engineer among the reviewers, regardless of tier.
5. Review evidence is retained. The review record (who approved, when, against which commit) is retained as control evidence and is auditable.

Small Teams Still Separate Author From Approver

On a five-person team the temptation is to let a developer merge their own code because “there is no one else.” There is someone else. The separation of author from approver is the single most effective software control CERG mandates, and it does not scale away. If genuinely only one person can review a given change, that one person reviews it. The author still does not approve their own work.

6. Automated Security Testing: SAST, DAST, SCA

6.1 Static Application Security Testing (SAST)

SAST runs on every commit to a protected branch and in the developer loop where the toolchain supports it. SAST findings at High or Critical block the SAST gate. The SAST ruleset is owned by the Application Security Engineer and reviewed at least annually. False positives are suppressed with a recorded, reviewable justification, not by disabling the rule.

6.2 Dynamic Application Security Testing (DAST)

DAST runs against a deployed pre-production instance for Tier 1 software and is recommended for Tier 2. DAST covers the OWASP application risk categories at minimum. High and Critical DAST findings block the DAST gate.

6.3 Software Composition Analysis (SCA)

SCA inventories third-party and open-source dependencies and checks them against known-vulnerability data. SCA runs on every build. A dependency carrying a known High or Critical vulnerability blocks the SCA gate until the dependency is updated, replaced, or an exception is filed. SCA output feeds the SBOM in Section 8.

6.4 Tooling Discipline

The specific tools are an implementation choice and are not named in this standard, so the standard survives a toolchain change. What the standard fixes is that SAST, DAST, and SCA capability exists, runs in the pipeline, and gates releases. An organization adopting CERG selects tools that meet that bar; the CERG-GOV-VAR-001 profile is the right place to record the selected toolchain.

7. Secrets in Code

This section has no risk-tier exception and no gate bypass.

1. Secrets are never committed. Passwords, API keys, tokens, private keys, connection strings, and any other credential are never written into source code, configuration files in the repository, build scripts, or container images.
2. Secrets scanning is mandatory. A secrets scanner runs on every commit and on the full repository history. A detected secret blocks the build.
3. A detected secret is treated as compromised. A secret that reaches a repository, even a private one, even briefly, is considered exposed. It is rotated immediately per CERG-STD-CR-001, and the exposure is logged. Removing the commit does not undo the exposure.
4. Secrets come from a secrets manager at runtime. Software retrieves credentials at runtime from the secrets management platform governed by CERG-STD-CR-001. Build-time injection from a secrets manager is acceptable; hard-coding is not.

A Secret in Git History Is a Secret in Production

The most common rationalization is “it was only in a private repo” or “I removed the commit.” Neither matters. A secret that touched version control has been copied to every clone, every fork, every backup, and every CI cache that ever pulled the repository. The only safe response is rotation. CERG treats a committed secret as a confirmed exposure, every time.

8. Dependencies and Software Bill of Materials

1. Every release carries an SBOM. A Software Bill of Materials listing every component and its version is generated for every release of Tier 1 and Tier 2 software, and for Tier 3 where the pipeline supports it. The SBOM is retained as a release artifact.
2. Dependencies are pinned. Builds resolve dependencies to specific, recorded versions. A build that resolves “latest” is not reproducible and is not permitted for Tier 1 or Tier 2.
3. Dependencies are monitored after release. A new vulnerability disclosed against a dependency already in production is a software vulnerability, handled per Section 11. SBOMs make this monitoring possible; that is their operational purpose.
4. New dependencies are assessed before adoption. Before a new third-party or open-source dependency is introduced, it is checked for maintenance health, known vulnerabilities, and license compatibility. A dependency with no recent maintenance is a supply chain risk.
5. Internal components are inventoried too. Reusable internal libraries are dependencies. They appear in the SBOM and are monitored like any other component.

9. Pipeline and Build Security

The build pipeline produces trusted software. A compromised pipeline produces compromised software that passes every other gate. The pipeline is therefore protected as a Tier 1 system regardless of what it builds.

1. Pipeline access is least-privilege and reviewed. Access to modify pipeline configuration, build steps, or deployment credentials follows CERG-STD-AC-001 and is reviewed on the access-review cadence.
2. Build steps are defined as code and reviewed. Pipeline definitions are version-controlled and subject to the code review requirements in Section 5. A change to how software is built is a security-sensitive change.
3. Builds are isolated. Build jobs run in ephemeral, isolated environments. A build does not run with standing production credentials.
4. Build provenance is attested. Tier 1 and Tier 2 releases carry verifiable provenance: what source commit, what build steps, what environment produced the artifact. This aligns with SLSA build-integrity levels.
5. Artifacts are integrity-protected. Released artifacts are signed or hashed so the deployment target can verify it is deploying what the pipeline produced.
6. Pipeline activity is logged. Build and deployment events are logged to the platform governed by CERG-STD-LM-001.

10. Infrastructure as Code

Infrastructure-as-code is software and is governed by this standard. Specifically:

1. IaC is subject to code review (Section 5) and to SAST-equivalent scanning for misconfiguration before apply.
2. IaC must not contain secrets (Section 7).
3. IaC that provisions production infrastructure is Tier 1 or Tier 2 by the same risk-tier logic in Section 3.2.
4. IaC-provisioned configuration must satisfy the secure configuration baselines in CERG-STD-CFG-001. IaC is the preferred mechanism for enforcing those baselines consistently.

11. Vulnerability Handling for Software

A security finding in CERG-managed software, whether found by SAST, DAST, SCA, code review, adversarial validation, or post-release disclosure, is a vulnerability.

1. Pre-production findings are engineering inputs. A finding caught before go-live is remediated before go-live, or the go-live is risk-accepted per CERG-PRC-AR-001. This is the pre-production versus post-production distinction from CERG-GOV-FRM-001 §4.3.
2. Post-production findings follow the VM procedure. A finding in released, operating software is a managed vulnerability and is remediated against the SLAs in CERG-PRC-VM-001.
3. No silent aging. A software finding is closed or risk-accepted. It is never simply moved down a backlog until it is forgotten. This is Principle 4.

12. Roles and Responsibilities

Roles below are the canonical role names from CERG-GOV-OM-001 §6.1.

13. Regulatory and Framework Alignment Summary

14. Document Control

Revision History

Review Triggers

• Revision of the NIST Secure Software Development Framework (800-218)
• Material change to the organization’s build toolchain or CI/CD platform
• A significant software-related security incident
• Internal audit or regulatory finding affecting software development
• Direction from the CISO

Cyber Engineering owns this document. The Engineering Pillar Leader (Application Security) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes.

Related Documents

Source: standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md · Download .md · View on GitHub