Common Requirements For Secure Software Development Practices

Executive Order (EO) 14028

The following application security controls are applicable to EO 14028, Sec. 4. Enhancing Software Supply Chain Security.:

• (A) using administratively separate build environments.

• (D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software.

• (E) employing encryption for data.

• (F)(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section.

• (F)(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code.

• (F)(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.

• (F)(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated.

• (F)(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.

• (F)(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.

• (F)(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process.

• (F)(ix) attesting to conformity with secure software development practices.

• (F)(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

​

NIST SP 800-171 [Cybersecurity Maturity Model Certification (CMMC)]

The following application security controls are applicable to NIST SP 800-171 and CMMC:

• 3.4.1 [CM.L2-3.4.1] - Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

• 3.13.2 [SC.L2-3.13.2] - Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

• 3.13.13 [SC.L2-3.13.13] - Control and monitor the use of mobile code.

​

NIST SP 800-53

The following application security controls are applicable to NIST SP 800-153 R5:

• ​SA-3 - System Development Life Cycle

• SA-3(2) - Use of Live or Operational Data

• SA-4 - Acquisition Process

• SA-4(3) - Development Methods, Techniques and Practices

• SA-4(9) - Functions, Ports, Protocols and Services In Use

• SA-8 - Security and Privacy Engineering Principles

• SA-8(28) - Acceptable Security

• SA-8(32) - Sufficient Documentation

• SA-8(33) - Minimization 

• SA-10 - Developer Configuration Management

• SA-11 - Developer Security Testing and Evaluation

• SA-11(1) - Static Code Analysis

• SA-11(2) - Threat Modeling and Vulnerability Analysis

• SA-11(3) - Independent Verification of Assessment Plans and Evidence

• SA-11(4) - Manual Code Reviews

• SA-11(5) - Penetration Testing

• SA-11(6) - Attack Surface Reviews

• SA-11(7) - Verify Scoping of Testing and Evaluation

• SA-11(8) - Dynamic Code Analysis

• SA-15 - Development Process, Standards and Tools

• SA-15(1) - Quality Metrics

• SA-15(2) - Security and Privacy Tracking Tools

• SA-15(3) - Criticality Analysis

• SA-15(5) - Attack Surface Reduction

• SA-15(6) - Continuous Improvement

• SA-15(7) - Automated Vulnerability Analysis

• SA-15(8) - Reuse of Threat and Vulnerability Information

• SA-15(10) - Incident Response Plan

• SA-15(11) - Archive System or Component

• SA-15(12) - Minimize Personally Identifiable Information

• SA-16 - Developer-Provided Training

• SA-17 - Developer Security and Privacy Architecture and Design

• SA-17(1) - Formal Policy Model

• SA-17(2) - Security-Relevant Components

• SA-17(5) - Conceptually Simple Design

• SA-17(6) - Structure for Testing

• SA-17(7) - Structure for Least Privilege

• SA-21 - Developer Screening

• SA-22 - Unsupported System Components

• SA-23 - Specialization

​

Payment Card Industry Data Security Standard (PCI DSS) v4.0

The following application security controls are applicable to PCI DSS v4:

• 6.2.1 - Bespoke and custom software are developed securely, as follows:

  • Based on industry standards and/or best practices for secure development.

  • In accordance with PCI DSS (for example, secure authentication and logging).

  • Incorporating consideration of information security issues during each stage of the software development lifecycle.

• 6.2.2 - Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:

  • On software security relevant to their job function and development languages.

  • Including secure software design and secure coding techniques.

  • Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.

• 6.2.3 - Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:

  • Code reviews ensure code is developed according to secure coding guidelines.

  • Code reviews look for both existing and emerging software vulnerabilities.

  • Appropriate corrections are implemented prior to release.

• 6.2.3.1 - If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:

  • Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.

  • Reviewed and approved by management prior to release.

• 6.2.4 - Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

  • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.

  • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.

  • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.

  • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).

  • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.

  • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.

• 6.3.1 - Security vulnerabilities are identified and managed as follows:

  • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).

  • Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.

  • Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.

  • Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.

• 6.3.2 - An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.

• 6.3.3 - All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

  • Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.

  • All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).

• 6.5.6 - Test data and test accounts are removed from system components before the system goes into production.

​

Center for Internet Security (CIS) v8

The following application security controls are applicable to CIS v8:

• 16.1 - Establish and Maintain a Secure Application Development Process

• 16.2 - Establish and Maintain a Process to Accept and Address Software Vulnerabilities

• 16.7 - Use Standard Hardening Configuration Templates for Application Infrastructure

• 16.9 - Train Developers in Application Security Concepts and Secure Coding

• 16.10 - Apply Secure Design Principles in Application Architectures

• 16.11 - Leverage Vetted Modules or Services for Application Security Components

• 16.12 - Implement Code-Level Security Checks

• 16.13 - Conduct Application Penetration Testing

• 16.14 - Conduct Threat Modeling

 

ISO 27002:2013

The following application security controls are applicable to ISO 27002:2013:

• 14.2.1 - Secure development policy

• 14.2.2 - System change control procedures

• 14.2.3 - Technical review of applications after operating platform changes

• 14.2.4 - Restrictions on changes to software packages

• 14.2.5 - Secure system engineering principles

• 14.2.6 - Secure development environment

• 14.2.7 - Outsourced development

• 14.2.8 - System security testing

• 14.2.9 - System acceptance testing

• 14.3.1 - Protection of test data

​

ISO 27002:2022

The following application security controls are applicable to ISO 27002:2022:

• 8.24 - Use of cryptography

• 8.25 - Secure development life cycle

• 8.26 - Application security requirements

• 8.27 - Secure system architecture and engineering principles

• 8.28 - Secure coding

• 8.29 - Security testing in development and acceptance

• 8.30 - Outsourced development

• 8.31 - Separation of development, test and production environments

• 8.32 - Change Management

• 8.33 - Test information

• 8.34 - Protection of information systems during audit testing

​