Skip to content

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.

Implementation Examples
  • Example 1: 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.\nExample 2: Choose testing methods based on the stage of the software.
References
  • BSAFSS: TV.3
  • BSIMM: PT2.3
  • IEC62443: SVV-1, SVV-2, SVV-3, SVV-4, SVV-5
  • NISTLABEL: 2.2.2.2
  • SCSIC: Peer Reviews and Security Testing
  • SP80053: RA-05, SA-11, SA-15
  • SP800181: SP-DEV-001, SP-DEV-002; T0456; K0013, K0039, K0070, K0153, K0165, K0342, K0367, K0536, K0624; S0001, S0015, S0026, S0061, S0083, S0112, S0135

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.

Implementation Examples
  • Example 1: Perform robust functional testing of security features, including failure path testing.\nExample 2: Integrate dynamic vulnerability testing into the project's automated test suite.\nExample 3: Incorporate tests for previously reported vulnerabilities into the project's test suite to ensure that errors are not reintroduced.\nExample 4: Take into consideration the infrastructures and technology stacks that the software will be used with in production when developing test plans.\nExample 5: Use fuzz testing tools to find issues with input handling.\nExample 6: If resources are available, use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios.\nExample 7: Identify and record the root causes of discovered issues.\nExample 8: Document lessons learned from code testing in a wiki that developers can access and search.\nExample 9: Use source code, design records, and other resources when developing test plans.\nExample 10: Identify third-party dependencies, and conduct robust tests to exercise the functionality that uses these dependencies.
References
  • BSAFSS: TV.3, TV.5, PD.1-4
  • BSIMM: ST1.1, ST1.3, ST1.4, ST2.4, ST2.5, ST2.6, ST3.3, ST3.4, ST3.5, ST3.6, PT1.1, PT1.2, PT1.3, PT3.1
  • IDASoar: 7, 8, 10, 11, 38, 39, 43, 44, 48, 55, 56, 57
  • IEC62443: SM-5, SM-13, SI-1, SVV-1, SVV-2, SVV-3, SVV-4, SVV-5
  • IR8397: 2.6, 2.7, 2.8, 2.9, 2.10, 2.11
  • ISO27034: 7.3.6
  • MSSDL: 10, 11
  • NISTLABEL: 2.2.2.2
  • OWASPMASVS: 7.5
  • OWASPSAMM: ST1-A, ST1-B, ST2-A, ST2-B, ST3-A
  • PCISSLC: 4.1
  • SCAGILE: Operational Security Tasks 10, 11; Tasks Requiring the Help of Security Experts 4, 5, 6, 7
  • SCFPSSD: Perform Dynamic Analysis Security Testing, Fuzz Parsers, Network Vulnerability Scanning, Perform Automated Functional Testing of Security Features/Mitigations, Perform Penetration Testing
  • SCSIC: Peer Reviews and Security Testing
  • SP80053: CA-02, CM-03, CM-09, RA-05, RA-05(03), SA-11, SA-11(05), SA-11(08), SA-15, SA-15(07), SI-02
  • SP800161: CA-02, CM-03
  • SP800181: SP-DEV-001, SP-DEV-002; T0013, T0028, T0169, T0176, T0253, T0266, T0456, T0516; K0009, K0039, K0070, K0272, K0339, K0342, K0362, K0536, K0624; S0001, S0015, S0046, S0051, S0078, S0081, S0083, S0135, S0137, S0167, S0242; A0015