Secure Software Development Practices (SSDP)

Secure Software Development Practices (SSDP) are a set of guidelines and principles that aim to ensure that software is developed in a way that takes into account security considerations. These practices can help reduce the risk of vulnerabilities and security flaws in software. Some examples of secure software development practices include:

NIST SP 800-160 - Gold Standard For Secure Development

National Institute of Standards and Technology (NIST) SP 800-160, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, is the "gold standard for secure development" and provides guidelines and recommendations for integrating security into the design and development of systems, applications and services, with a focus on trustworthiness and security. NIST SP 800-160 covers a wide range of topics related to systems security engineering, including:

NIST SP 800-160 is intended to serve as a resource for organizations seeking to design and develop secure systems, and as a guide for professionals working in the field of systems security engineering.

Operationalizing Secure Software Development Practices (SSDP)

This reality facing software providers (organizations making software) is that developers and architects must adopt a “secure development mindset” that influences how their code will affect not only the secure functionality of the application, service, or process; but how it affects the privacy and security of individuals who are not necessarily users, but anyone who is potentially affected by the application under development. Security and privacy must be considered during development and appropriately validated before it is released “into the wild.”

There is a growing need for organizations to implement those strategic cyber resiliency design principles that are established by NIST SP 800-160, Vol 2, Rev 1:

Cyber resiliency is the ability to anticipate, withstand, recover from and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources. From a risk management perspective, cyber resiliency is intended to reduce the mission, business, organizational, or sector risk of depending on cyber resources.

Executive Order (EO) 14028: Enhancing Software Supply Chain Security

Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, is focused on enhancing "software supply chain security" and is essentially a trickle-down set of requirements for Secure Software Development Practices (SSDP).

EO 14028 directs NIST to publish guidance on practices for software supply chain security. EO 14028 Section 4e contains ten (10) subsections, each of which specifies actions or outcomes for software producers, such as Commercial-Off-The-Shelf (COTS) product vendors, Government-Off-The-Shelf (GOTS) software developers, contractors, and other custom software developers. Per the EO, SSDP should be integrated throughout software life cycles for three (3) reasons:

‚ÄčNIST SP 800-218 addresses EO 14028 Section 4e from a software producer viewpoint, where the software producers are the entities that implement SSDF practices. EO 14028 Section 4k explains that federal agencies will need to comply with NIST guidelines. In this context, federal agencies are software purchasers, not software producers, so additional guidance from the US Government is needed to address EO 14028 Section 4e from a software purchaser viewpoint. However, when a federal agency (purchaser) acquires software or a product containing software, the agency is required to receive attestation from the software producer that the software’s development complies with US Government-specified secure software development practices.

Software Supply Chain Security

Software supply chain security refers to the measures taken to protect the integrity and reliability of software throughout the software development and delivery process. This includes measures to protect against the introduction of vulnerabilities or malicious code into the software, as well as measures to ensure that the software is delivered to the intended recipients in a secure manner. There are several aspects to software supply chain security, including:

By implementing effective software supply chain security measures, organizations can help ensure that their software is as secure as possible and reduce the risk of vulnerabilities and security incidents.

Demonstrating Compliance With EO 14028

It is expected that Federal agencies will request artifacts from the software producer that support its attestation of conformity with the SSDP described in EO 14028 Section 4e subsections (i), (iii) and (iv). With EO 14028, it is specifically targeted at America's supply chain security. This is where it will be nearly impossible for software providers to avoid:

Software providers will invariably be impacted by EO 14028 due to trickle-down requirements. While a software provider may not categorize itself as a "Federal contractor" or a "Defense contractor" since it does not directly sell to the US Government, it will still get caught up in requirements that flow down from its customers that do sell products or provide services to the US Government. This is just the reality of how the Federal Acquisition Regulation (FAR) and Defense Acquisition Regulations System (DFARS) clauses work - those clauses trickle down throughout the supply chain.

Attesting to Conformity with Secure Software Development Practices (SSDP)

NIST defined minimum recommendations for Federal agencies as they acquire software or a product containing software. These recommendations are intended to assist Federal agencies and software producers in communicating clearly with each other regarding secure software development artifacts, attestation, and conformity:

Use the SSDF’s terminology and structure to organize communications about secure software development requirements. This enables all software producers to use the same lexicon when attesting to conformity for federal agencies. Software producers can map their secure development methodology to the SSDF’s secure software development practices or associated informative references.

Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle. With the highly dynamic nature of software today, attesting to how things were and are done on an ongoing basis (processes and procedures) is typically more valuable than attesting to how things were done for a specific software release generated by one instance of those processes. This is especially true for post-release practices such as vulnerability disclosure and response, where processes might not yet have been performed for the latest release.

Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required. First-party attestation is recommended for meeting the EO 14028 requirements. This is consistent with the guidance in NIST SP 800-161 Rev. 1 (Second Draft), which states in Section 3.1.2: “There are a variety of acceptable validation and revalidation methods, such as requisite certifications, site visits, third-party assessment, or self-attestation. The type and rigor of the required methods should be commensurate to the criticality of the service or product being acquired and the corresponding assurance requirements.”

When requesting artifacts of conformance, request high-level artifacts. The software producer should be able to trace the practices summarized in the high-level artifacts to the corresponding low-level artifacts that are generated by those practices. Asking for low-level artifacts for a particular software release is not recommended for meeting the requirements of EO 14028, but may be needed to meet other agency requirements. Reasons for avoiding low-level artifacts include the following:


Browse Our Products

  • Digital Security Program (DSP)

    Digital Security Program (DSP) - SCF Policy Template

    Secure Controls Framework (SCF)

    Secure Controls Framework (SCF) "Premium Content" - Expertise-Class Policies, Control Objectives, Standards, Guidelines, Controls & Metrics. Product Walkthrough Video This short product walkthrough video is designed to give a brief overview about...

    Choose Options
  • Cybersecurity Supply Chain Risk Management Strategy & Implementation Plan (C-SCRM SIP)

    C-SCRM Strategy & Implementation Plan (C-SCRM SIP)


      NIST SP 800-161 Rev 1 - Cybersecurity Supply Chain Risk Management Strategy & Implementation Plan (C-SCRM SIP) Product Walkthrough Video This short product walkthrough video is designed to give a brief overview about what the C-SCRM is...

    Choose Options
  • C-SCRM Compliance Bundle 1 - NIST SP 800-161 R1-based C-SCRM Program

    C-SCRM Bundle 1: CDPP version (ISO or NIST alignment)


    Cybersecurity Supply Chain Risk Management (C-SCRM) Bundle #1 - CDPP Version  (40% discount) This is a bundle that includes the following thirteen (13) ComplianceForge products that are focused on operationalizing Cybersecurity Supply Chain Risk...

    Choose Options
  • C-SCRM Compliance Bundle 2 - NIST SP 800-161 R1-based C-SCRM Program

    C-SCRM Bundle 2: DSP version (SCF alignment)


    Cybersecurity Supply Chain Risk Management (C-SCRM) Bundle #2 - DSP Version (45% discount) This is a bundle that includes the following thirteen (13) ComplianceForge products that are focused on operationalizing Cybersecurity Supply Chain Risk...

    Choose Options

Learn More About Cybersecurity & Data Privacy