top of page

Secure Software Development Practices (SSDP) Certification

The Secure Code Alliance (SCA) was formed to address the need that organizations have to ensure its developers are aware of and implement Secure Software Development Practices (SSDP) in order to minimize the threat posed by malicious actors against the organization’s applications, services, and processes. 

 

The SCA is focused on technical competence. Applicants for the Certified SCA Practitioner (CSCAP) and Certified SCA Architect (CSCAA) certifications are expected to invest the requisite time and effort necessary to familiarize themselves with industry-recognized secure development practices, which form the basis of the SCA Body of Knowledge (SCA-BoK). These certifications are for software developers and architects, not project/program managers, security managers, or IT directors. The focus is purely on SSDP concepts that developers and architects deal with on a daily basis.

 

For practical purposes, individuals who earn a CSCAP or CSCAA certifications have demonstrated a level of competence necessary to ensure that the security of an organization’s applications, services, and processes are assessed throughout their operational life to reduce risks to the organization and its clients. These certifications are valid for a period of three (3) years from the date of issue of the Certificate of Competency (CoC), at which point the certification expires and will need to be renewed through a re-examination.

SCA Practitioner (Horizontal).png

Software developers (practitioners) are expected to use Secure Development Lifecycle (SDL) processes for new systems, system upgrades, or systems that are being repurposed. These processes can be employed at any stage of the system lifecycle and can take advantage of any system or software development methodology, including agile, spiral, or waterfall.

SCA Architect (Horizontal).png

Software architects (architects) are expected to employ cyber resiliency constructs (e.g., goals, objectives, techniques, approaches and design principles), as well as the analytic and lifecycle processes, to tailor them to the technical, operational, and threat environments for which the architect’s systems need to be engineered.

Developing Security & Privacy by Design

The SCA is focused on technical competence. The Developing Security & Privacy by Design (DSPD) initiative is a conformity assessment methodology designed to issue individual-level certifications, specific to Secure Software Development Practices (SSDP).

 

Application developers (developers) are vital to the success of any organization, regardless of the industry. Developers create the tools that we all use, from operating systems to mobile apps, backend programming, firmware, front-end interface design, and other forms of applications. Based on the new realities of the interconnected world that we live in, developers need to implement SSDP in order to protect their code from malicious attacks. By following SSDP, developers serve a crucial role in helping ensure security and safety, not just within an organization, but across the supply chain and society, as a whole.

 

Developers are in a unique position where they often have access to a wealth of sensitive information. As such, it is vital that developers create code with both security and privacy in mind; since improper coding practices can lead to exploitable vulnerabilities that enable hostile actors to affect the Confidentiality, Integrity, Availability, and Safety (CIAS) of those affected systems, applications and/or services.

Secure Software Development Practices (SSDP) - CIAS model (orange).png

  • CONFIDENTIALITY addresses preserving authorized restrictions on access and disclosure to authorized users and services, including means for protecting personal privacy and proprietary information.

​

  • INTEGRITY addresses guarding against improper modification or destruction, including ensuring non-repudiation and authenticity.

​

  • AVAILABILITY addresses timely, reliable access to data, systems, and services for authorized users

​

  • SAFETY addresses reducing risks associated with technologies that could fail or be manipulated by nefarious actors to cause death, injury, illness, damage to, or loss of equipment.

Application Developer & Architect Certification

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.”

 

The SCA supports the strategic cyber resiliency design principles that are established by NIST SP 800-160, Vol 2, Rev 1:

  • Focus on common critical assets;

  • Support agility and architect for adaptability;

  • Reduce attack surfaces;

  • Assume compromised resources; and

  • Expect adversaries to evolve.

 

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 - Mandate For Secure Software Development Practices

Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, directs the National Institute of Standards and Technology (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. 

 

Accordingly, Secure Software Development Practices (SSDP) should be integrated throughout software life cycles for three (3) reasons:

  1. To reduce the number of vulnerabilities in released software;

  2. To reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities; and

  3. To address the root causes of vulnerabilities to prevent recurrences. 

​

NIST SP 800-218 addresses EO 14028 Section 4e from a software producer viewpoint. The software producers are the ones who 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.

 

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).

EO 14028

Trickle-Down Software Provider Requirements

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.

​

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:

  • Implementing Secure Software Development Practices (SSDP); and

  • Having the artifacts (e.g., evidence) that the software provider (including its developers and architects) have implemented the SSDP throughout the lifecycle of the applications, service and/or process.

Attesting to Conformity with Secure Software Development Practices (SSDP)

NIST defined the following 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:

  1. 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.

  2. 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.

  3. 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.”

  4. 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:

    • Low-level artifacts provide a snapshot in time of only a small aspect of secure software development, whereas high-level artifacts can provide a big-picture view of how secure software development is performed.

    • Artifacts should address the needs of the audience receiving them, thus providing the necessary information in a usable format for that audience. Understanding low-level artifacts require the agency to expend considerable technical resources and expertise in analyzing them and determining how to consider them within the context of the broader secure software development practices.

    • Low-level artifacts often contain intellectual property or other proprietary information, or details that attackers could use for hostile purposes, so accepting low-level artifacts gives the agency additional sensitive information to protect. These minimum recommendations apply to attestation for all software within the scope of this guidance procured by federal agencies and they should be part of each agency’s processes. The recommendations are not intended to replace more stringent requirements for secure software development that federal agencies may have.

bottom of page