PW – Produce Well-Secured Software

NIST SP 800-218 (SSDF) – PW – Produce Well-Secured Software

1.Kravtext (engelskt original)#

PW.1 – Design Software to Meet Security Requirements and Mitigate Security Risks#

Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.

PW.1.1

Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software.

Examples:

Train the development team (security champions, in particular) or collaborate with a risk modeling expert to create models and analyze how to use a risk-based approach to communicate the risks and determine how to address them, including implementing mitigations.
Perform more rigorous assessments for high-risk areas, such as protecting sensitive data and safeguarding identification, authentication, and access control, including credential management.
Review vulnerability reports and statistics for previous software to inform the security risk assessment.
Use data classification methods to identify and characterize each type of data that the software will interact with.

PW.1.2

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

Examples:

Record the response to each risk, including how mitigations are to be achieved and what the rationales are for any approved exceptions to the security requirements. Add any mitigations to the software’s security requirements.
Maintain records of design decisions, risk responses, and approved exceptions that can be used for auditing and maintenance purposes throughout the rest of the software life cycle.
Periodically re-evaluate all approved exceptions to the security requirements, and implement changes as needed.

PW.1.3

Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services. .Formerly PW.4.3

Examples:

Maintain one or more software repositories of modules for supporting standardized security features and services.
Determine secure configurations for modules for supporting standardized security features and services, and make these configurations available (e.g., as configuration-as-code) so developers can readily use them.
Define criteria for which security features and services must be supported by software to be developed.

PW.2 – Review the Software Design to Verify Compliance with Security Requirements and Risk Information#

Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.

PW.2.1

Have 1) a qualified person (or people) who were not involved with the design and/or 2) automated processes instantiated in the toolchain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information.

Examples:

Review the software design to confirm that it addresses applicable security requirements.
Review the risk models created during software design to determine if they appear to adequately identify the risks.
Review the software design to confirm that it satisfactorily addresses the risks identified by the risk models.
Have the software’s designer correct failures to meet the requirements.
Change the design and/or the risk response strategy if the security requirements cannot be met.
Record the findings of design reviews to serve as artifacts (e.g., in the software specification, in the issue tracking system, in the threat model).

PW.4 – Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality#

Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.

PW.4.1

Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software.

Examples:

Review and evaluate third-party software components in the context of their expected use. If a component is to be used in a substantially different way in the future, perform the review and evaluation again with that new context in mind.
Determine secure configurations for software components, and make these available (e.g., as configuration-as-code) so developers can readily use the configurations.
Obtain provenance information (e.g., SBOM, source composition analysis, binary software composition analysis) for each software component, and analyze that information to better assess the risk that the component may introduce.
Establish one or more software repositories to host sanctioned and vetted open-source components.
Maintain a list of organization-approved commercial software components and component versions along with their provenance data.
Designate which components must be included in software to be developed.
Implement processes to update deployed software components to newer versions, and retain older versions of software components until all transitions from those versions have been completed successfully.
If the integrity or provenance of acquired binaries cannot be confirmed, build binaries from source code after verifying the source code’s integrity and provenance.

PW.4.2

Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components.

Examples:

Follow organization-established security practices for secure software development when creating and maintaining the components.
Determine secure configurations for software components, and make these available (e.g., as configuration-as-code) so developers can readily use the configurations.
Maintain one or more software repositories for these components.
Designate which components must be included in software to be developed.
Implement processes to update deployed software components to newer versions, and maintain older versions of software components until all transitions from those versions have been completed successfully.

PW.4.4

Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.

Examples:

Regularly check whether there are publicly known vulnerabilities in the software modules and services that vendors have not yet fixed.
Build into the toolchain automatic detection of known vulnerabilities in software components.
Use existing results from commercial services for vetting the software modules and services.
Ensure that each software component is still actively maintained and has not reached end of life; this should include new vulnerabilities found in the software being remediated.
Determine a plan of action for each software component that is no longer being maintained or will not be available in the near future.
Confirm the integrity of software components through digital signatures or other mechanisms.
Review, analyze, and/or test code. See PW.7 and PW.8.

PW.5 – Create Source Code by Adhering to Secure Coding Practices#

Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.

PW.5.1

Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.

Examples:

Validate all inputs, and validate and properly encode all outputs.
Avoid using unsafe functions and calls.
Detect errors, and handle them gracefully.
Provide logging and tracing capabilities.
Use development environments with automated features that encourage or require the use of secure coding practices with just-in-time training-in-place.
Follow procedures for manually ensuring compliance with secure coding practices when automated methods are insufficient or unavailable.
Use tools (e.g., linters, formatters) to standardize the style and formatting of the source code.
Check for other vulnerabilities that are common to the development languages and environment.
Have the developer review their own human-readable code to complement (not replace) code review performed by other people or tools. See PW.7.

PW.6 – Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security#

Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.

PW.6.1

Use compiler, interpreter, and build tools that offer features to improve executable security.

Examples:

Use up-to-date versions of compiler, interpreter, and build tools.
Follow change management processes when deploying or updating compiler, interpreter, and build tools, and audit all unexpected changes to tools.
Regularly validate the authenticity and integrity of compiler, interpreter, and build tools. See PO.3.

PW.6.2

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

Examples:

Enable compiler features that produce warnings for poorly secured code during the compilation process.
Implement the “clean build” concept, where all compiler warnings are treated as errors and eliminated except those determined to be false positives or irrelevant.
Perform all builds in a dedicated, highly controlled build environment.
Enable compiler features that randomize or obfuscate execution characteristics, such as memory location usage, that would otherwise be predictable and thus potentially exploitable.
Test to ensure that the features are working as expected and are not inadvertently causing any operational issues or other problems.
Continuously verify that the approved configurations are being used.
Make the approved tool configurations available as configuration-as-code so developers can readily use them.

PW.7 – Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements#

Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems human-readable.

PW.7.1

Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization.

Examples:

Follow the organization’s policies or guidelines for when code review should be performed and how it should be conducted. This may include third-party code and reusable code modules written in-house.
Follow the organization’s policies or guidelines for when code analysis should be performed and how it should be conducted.
Choose code review and/or analysis methods based on the stage of the software.

PW.7.2

Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.

Examples:

Perform peer review of code, and review any existing code review, analysis, or testing results as part of the peer review.
Use expert reviewers to check code for backdoors and other malicious content.
Use peer reviewing tools that facilitate the peer review process, and document all discussions and other feedback.
Use a static analysis tool to automatically check code for vulnerabilities and compliance with the organization’s secure coding standards with a human reviewing the issues reported by the tool and remediating them as necessary.
Use review checklists to verify that the code complies with the requirements.
Use automated tools to identify and remediate documented and verified unsafe software practices on a continuous basis as human-readable code is checked into the code repository.
Identify and document the root causes of discovered issues.
Document lessons learned from code review and analysis in a wiki that developers can access and search.

PW.8 – Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements#

Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.

PW.8.1

Determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing and, if so, which types of testing should be used.

Examples:

Follow the organization’s policies or guidelines for when code testing should be performed and how it should be conducted (e.g., within a sandboxed environment). This may include third-party executable code and reusable executable code modules written in-house.
Choose testing methods based on the stage of the software.

PW.8.2

Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.

Examples:

Perform robust functional testing of security features.
Integrate dynamic vulnerability testing into the project’s automated test suite.
Incorporate tests for previously reported vulnerabilities into the project’s test suite to ensure that errors are not reintroduced.
Take into consideration the infrastructures and technology stacks that the software will be used with in production when developing test plans.
Use fuzz testing tools to find issues with input handling.
If resources are available, use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios.
Identify and record the root causes of discovered issues.
Document lessons learned from code testing in a wiki that developers can access and search.
Use source code, design records, and other resources when developing test plans.

PW.9 – Configure Software to Have Secure Settings by Default#

Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

PW.9.1

Define a secure baseline by determining how to configure each setting that has an effect on security or a security-related setting so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services.

Examples:

Conduct testing to ensure that the settings, including the default settings, are working as expected and are not inadvertently causing any security weaknesses, operational issues, or other problems.

PW.9.2

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

Examples:

Verify that the approved configuration is in place for the software.
Document each setting’s purpose, options, default value, security relevance, potential operational impact, and relationships with other settings.
Use authoritative programmatic technical mechanisms to record how each setting can be implemented and assessed by software administrators.
Store the default configuration in a usable format and follow change control practices for modifying it (e.g., configuration-as-code).

National Institute of Standards and Technology, OSCAL release 1.0.0. Republished courtesy of the National Institute of Standards and Technology. CC0 1.0. Source.