NIST SP 800-218

Perform the code review and/or code analysis based on the organization's secure coding standards, and record and triage the discovered issues.

• Code review/static analysis findings and triage

• No code review
• Findings not triaged

Design, scope, execute, and document the testing of executable code (dynamic analysis), and record and triage the discovered issues.

• Dynamic test plans, execution, and triaged results

• No dynamic/executable security testing

Implement the default settings (or groups of settings), and document each setting for software administrators.

• Documented and implemented secure default settings

• Insecure defaults shipped
• Settings undocumented

Review, analyze, and/or test the software's code to identify or confirm the presence of previously undetected vulnerabilities.

• Code review/test results identifying vulnerabilities

• No proactive vulnerability discovery

Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support it.

• Vulnerability disclosure and remediation policy

• No disclosure policy or intake channel

Track and maintain the software's security requirements, risks, and design decisions.

• Record of security requirements, risks, and design decisions

• Design decisions and risks not tracked

Where appropriate, build in support for using standardized security features and services rather than creating proprietary implementations.

• Use of standardized security features/services

• Proprietary security implementations reinvented

Have a qualified person who was not involved with the design review it to confirm it meets the security requirements and satisfactorily addresses identified risks.

• Independent design review records

• Design not reviewed by an independent qualified person

Create and maintain well-secured software components in-house following SSDF practices to meet common internal needs.

• Inventory of well-secured in-house components

• Reused components not maintained to SSDF practices

Determine which compiler, interpreter, and build tool security features to use and how each should be configured, then implement the configurations.

• Compiler/build tool security feature configuration

• Security flags/hardening not enabled in builds

Plan and implement risk responses for vulnerabilities, including remediation, mitigation, or acceptance with rationale.

• Remediation plans and implementation records

• Vulnerabilities accepted without rationale
• No remediation SLA

Analyze identified vulnerabilities to determine if there are systemic issues, and proactively fix similar vulnerabilities elsewhere in the software.

• Analysis identifying and fixing similar vulnerabilities

• Similar vulnerabilities left unaddressed

Review the software development process and update it as appropriate to prevent the root causes of vulnerabilities from recurring in future releases.

• SDLC process updates to prevent recurrence

• Root causes not fed back into the SDLC

Document lessons learned from root cause analysis and the response to share within the organization and improve secure development practices.

• Documented lessons learned shared across teams

• No lessons-learned capture or sharing

Communicate the organization's software security requirements to all third parties who provide commercial software components for reuse.

• Security requirements communicated to third-party component providers
• Contract/agreement clauses

• Third-party security expectations undocumented

Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all personnel with software-development-related roles.

• Management commitment statement
• Communication to development staff

• No executive sponsorship of secure development

Configure tools to generate artifacts of their support of secure software development practices.

• Toolchain config that emits security artifacts/logs

• Tools do not produce evidence of secure practices

Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria for software security checks.

• Processes to gather and safeguard security-check information

• Security check data not captured or protected

Secure and harden development endpoints (the systems used to perform development) to perform development-related tasks with a reduced attack surface.

• Development endpoint hardening standard and evidence

• Developer endpoints unhardened

Identify and document security requirements for developed software, considering customer obligations, regulatory expectations, internal policy, and known threats. Make the requirements accessible to development teams and update them as the threat landscape changes.

• secure development policy
• requirements traceability between policy and product backlog
• annual review record of security requirements
• examples of new requirements driven by emerging threats

• requirements live in security wiki but are never referenced in tickets
• regulatory mapping not refreshed after new obligations apply
• no mechanism for security to inject new requirements into backlogs

Configure development tools, source control, build systems, and artifact repositories to enforce the security requirements. Automate enforcement so that compliance is the default behavior rather than a manual checklist.

• toolchain hardening baseline
• policy as code in CI configuration
• exception process for bypassing tool gates
• monthly compliance metrics across repositories

• tool gates can be bypassed by anyone with admin in CI
• no enforcement for legacy repositories
• exception process exists but is rarely used because gates are weak

Define and assign roles and responsibilities for secure software development across product, engineering, security, and operations. Make the responsibilities measurable so that ownership for security work is clear.

• RACI for SSDF practices
• security champion programme charter
• individual security objectives in performance management
• annual review of role definitions

• security is responsible and accountable for everything in the RACI
• no security champions assigned in product teams
• performance objectives do not reflect security work

Provide role appropriate secure development training and maintain skills through ongoing learning. Track completion and refresh training when standards or technologies change.

• secure coding training catalog by role
• completion records integrated with HR systems
• annual refresh policy
• metrics tying training to defect reduction

• training is the same one off course for every role
• completion not enforced and not visible to managers
• no measurement of training effectiveness

Select tools that meet the security needs of the development environment. Evaluate tools for their own security and for the assurance they provide about the software they process.

• tool selection criteria document
• vendor security assessments
• configuration review for chosen tools
• deprecation policy for unsupported tools

• tools selected on price without security review
• vendor self attestations not validated
• deprecated tools remain in pipelines

Configure and integrate development tools so they enforce the secure development policy. Treat configuration as code and version control changes to it.

• configuration repository for CI and security tools
• drift detection alerts
• change approval log for tool configuration
• rollback procedure

• configuration drifts because changes are made in the UI
• no drift detection in place
• rollback procedure untested

Define criteria for assessing the security characteristics of software before release. Tie criteria to risk and to customer commitments so that release decisions are explicit.

• release security criteria document
• risk acceptance workflow
• release readiness review records
• metrics on releases with open critical findings

• release criteria exist but releases ship regardless of criteria
• no risk acceptance workflow tied to release
• criteria not differentiated by product risk tier

Implement and maintain secure environments for software development including source code repositories, build systems, and developer endpoints. Apply the same controls expected of production where the data sensitivity warrants.

• developer endpoint hardening standard
• build environment isolation design
• source control access review records
• monitoring coverage for development infrastructure

• developer laptops less monitored than production
• build agents share network space with corporate IT
• code signing keys held on developer endpoints

Design software so that it meets security requirements and mitigates known risks from the start. Use threat modelling to identify how an attacker could abuse the system and feed mitigations back into the design.

• threat model artifacts per significant feature
• design review records
• linkage between threat model findings and code changes
• training records for threat modelling facilitators

• threat models produced once at feature start, never updated
• no linkage from threat model findings to backlog tickets
• only the security team performs modelling

Acquire and reuse well secured software components rather than creating new ones for common functions. Track the origin and version of each component and verify its provenance.

• approved component catalog
• component intake review process
• provenance verification logs
• deprecation process for risky components

• no central catalog of approved components
• intake review skipped under time pressure
• components remain in use after the upstream project is abandoned

Verify that third party and open source components meet the same security requirements applied to in house code. Use static analysis, dependency analysis, and known vulnerability databases to support the decision.

• Software Composition Analysis configuration
• vulnerability database integration
• component approval workflow records
• license compliance checks

• vulnerability scans run but findings never break the build
• license risks not assessed
• newly added dependencies bypass review

Follow secure coding practices for input validation, output encoding, authentication, session management, error handling, and use of secure defaults. Apply practices consistently across languages used in the organization.

• secure coding standard per language
• linter or analyzer configuration to enforce standard
• training tied to standard
• examples of code review feedback citing standard

• standard exists for one language but not the rest of the stack
• linters disabled because they slow builds
• training not refreshed when standard changes

Configure compilers, linkers, and interpreters to use security focused options including stack protection, position independent code, and warnings as errors where feasible. Persist these options as part of the build configuration.

• compiler flag catalog by language
• build configuration committed to source control
• warnings as errors policy
• exception register for legacy components

• compiler flags vary across services with no central guidance
• warnings ignored to keep builds green
• interpreters run in unsafe modes for performance

Review the human readable source code to identify vulnerabilities. Use a combination of manual code review and automated static analysis tools tuned to the language and framework.

• code review policy
• static analysis tool inventory with tuning notes
• false positive triage process
• metrics on findings closed per release

• static analysis runs but findings are never triaged
• code review approval limited to functional concerns
• false positive rate so high that engineers ignore reports

Test executable software to detect vulnerabilities using dynamic application security testing, fuzz testing, and penetration testing on a defined cadence. Tie test scope to risk and feature changes.

• DAST integration in CI or scheduled scans
• fuzz testing harnesses for critical parsers
• annual penetration test reports
• remediation tracker tied to test findings

• DAST run only against pre production with no realistic data
• no fuzz testing despite parsing untrusted input
• penetration test findings tracked separately from product backlog

Ship software with secure default configuration so that customers receive a secure posture out of the box. Document the security implications of any settings that customers can change.

• default configuration review
• documentation of security implications of settings
• telemetry on customer adoption of insecure settings
• deprecation plan for unsafe defaults

• secure defaults rolled back after customer complaint
• documentation does not call out security implications
• no measurement of how customers configure the product

Apply controls to source code, infrastructure as code, and build scripts so that only authorized contributors can change them and all changes are reviewed and logged. Protect main branches and require pull request reviews.

• branch protection configuration
• code review policy and tool enforcement
• audit log retention for source control
• exception register for direct pushes

• main branch protection disabled in many repositories
• code review can be self approved
• audit logs lost when repositories migrate

Sign software releases and provide a mechanism for consumers to verify integrity. Publish hashes and signatures over a separate channel from the release artifact where possible.

• signing key custody documentation
• release signing pipeline step
• publication of verification instructions to consumers
• test that verification fails when artifact is altered

• signing keys held in CI environment variables
• consumers given no clear verification path
• signatures generated but never verified internally

Archive each release along with its source, build metadata, and dependencies. Retain the archive long enough to support incident response, customer support, and regulatory obligations.

• release archive policy
• storage layout for archived artifacts
• retention schedule by product
• demonstration of restoring a historical build

• only the binary archived without the corresponding source state
• retention shorter than support obligations
• no test of restoration

Produce a software bill of materials for each release in a machine readable format. Make it available to customers and use it internally to triage component vulnerabilities.

• SBOM generation in the build pipeline
• SBOM publication or delivery process
• internal SBOM index for vulnerability lookups
• SBOM format choice document (e.g. CycloneDX, SPDX)

• SBOM generated but never consumed for vulnerability triage
• no SBOM provided for legacy releases still under support
• SBOM does not include transitive dependencies

Continuously identify vulnerabilities in released software using internal testing, external reports, and intelligence from component upstreams. Confirm reproducibility and severity before treating findings.

• vulnerability disclosure policy and intake channel
• internal validation workflow
• severity rating model
• metrics on time from receipt to triage

• no published vulnerability disclosure channel
• researchers redirected to general support inbox
• validation backlog grows because triage is undertasked

Assess each vulnerability against business risk, exploitability, and customer impact, then prioritize remediation accordingly. Track remediation against agreed service level objectives by severity.

• vulnerability SLA matrix by severity
• remediation tracker with aging report
• exception process for accepted risk
• executive view of overdue vulnerabilities

• SLAs defined but routinely missed without escalation
• exceptions never expire
• no visibility into customer exposure when prioritizing

Perform root cause analysis on confirmed vulnerabilities so that systemic weaknesses are identified and remediated, not just individual instances. Feed the lessons back into design, coding, and testing practices.

• root cause analysis template
• log of systemic improvements driven by RCA
• training updates citing RCA outcomes
• metrics on recurrence of similar findings

• RCA performed only on incidents that draw external attention
• lessons not propagated to other teams
• training and standards never updated based on RCA