Secure SDLC, DevSecOps, and Governance

19.1 Secure Software Development Lifecycle (SSDLC)

Integrate security into:

Planning and requirements Architecture and threat modeling Implementation and peer review Automated and manual testing Build and artifact signing Deployment and configuration Monitoring and incident response Maintenance, patching, and end-of-life

19.2 Pull-request security checklist

Are trust-boundary inputs validated?

Are permissions enforced server-side?

Are queries, templates, commands, and paths handled safely?

Are secrets absent from code and logs?

Are dependencies justified and maintained?

Are error paths and resource limits safe?

Are positive and negative tests included?

Does the change alter threat model, data classification, or exposure?

Can the change be rolled back safely?

19.3 CI/CD security gates

A mature pipeline may include:

Formatting, linting, and type checks Unit and integration tests SAST and secret scanning Dependency/SCA and license checks Build and artifact provenance Container and IaC scans Software bill of materials generation Security regression tests Approval for high-risk changes

Signed artifact promotion and post-deploy verification Choose gates according to risk and avoid creating noisy checks that teams learn to ignore. Critical findings need ownership, deadlines, and a controlled exception process.

A pipeline as configuration (illustrative) _Not run — this is an illustrative GitHub Actions workflow. Replace <pinned-commit-sha> with the full commit SHA of the action version you reviewed, and install the scanners your organisation approves._

name: security-gate
on: [pull_request]
permissions:
  contents: read
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<pinned-commit-sha>
      - run: npm ci
      - run: npm run lint && npm run typecheck
      - run: npm test
      - run: npm audit --audit-level=high
      - name: Secret scan
        run: gitleaks detect --no-banner
      - name: SBOM
        run: npx @cyclonedx/cyclonedx-npm --output-file sbom.json

19.4 Vulnerability management

Track finding, affected asset, severity, exploitability, exposure, owner, due date, mitigation, fix version, verification, and residual risk. Define response times by severity and exposure. Exceptions should be time-limited, documented, approved by accountable owners, and reviewed.

19.5 Standards and guidance

Use the current versions and official materials relevant to the project:

OWASP Top 10 for web application risk awareness OWASP Application Security Verification Standard (ASVS) for testable security requirements

OWASP Cheat Sheet Series for implementation guidance OWASP API Security Top 10 for API risk awareness

NIST Secure Software Development Framework (SSDF) NIST Cybersecurity Framework (CSF) CWE for weakness classification

CVE and vendor advisories for known vulnerabilities CVSS for technical severity scoring

ISO/IEC 27001 and related controls where applicable ISO/SAE 21434 for road-vehicle cybersecurity engineering where applicable

MISRA guidance and language standards for relevant safety-critical C/C++ projects

Standards are not interchangeable. Select applicable editions and requirements with domain specialists; do not claim compliance based only on completing a checklist.

19.6 Security metrics

Useful metrics include:

Time to remediate by severity Age of overdue high-risk findings

Percentage of critical assets with owners Coverage of threat models for high-risk changes

Security regression test coverage for known defects Dependency patch latency Secret-leak response time

Incident recurrence and corrective-action closure Avoid metrics that reward hiding findings or closing tickets without verified remediation.

19.7 Security champions and collaboration

Security is shared among developers, architects, operations, product, QA, incident response, privacy, and leadership. Security champions can help teams interpret guidance, but they do not replace specialist review for high-risk designs.

Quiz

? A scanner produces hundreds of low-value findings on every build. What is the risk?
+ Teams learn to ignore it, and real findings get missed. :: Tune gates by risk and give critical findings owners.
- None — more findings means more security. :: Noise reduces attention.
- The build becomes faster. :: Unrelated.
- It satisfies compliance automatically. :: Checklists do not equal compliance.

? Which properties should a security exception have? (select all that apply)
+ An expiry date :: Exceptions are time-limited.
+ An accountable approver :: Someone owns the risk.
+ Regular review :: Context changes.
- Permanent status once approved :: The course requires time-limited exceptions.

? What does completing an ASVS checklist prove?
- Full regulatory compliance :: Standards are not interchangeable with legal obligations.
+ That specific listed requirements were verified, for the chosen level and scope :: Nothing more, nothing less.
- That the application has no vulnerabilities :: No checklist proves that.
- ISO/IEC 27001 certification :: That is a separate management-system certification.