[ISM] Web application logging:

Web application crashes and error messages are centrally logged.

[SSDF] Comprehensive security testing (SSS-03-02-01)

Define the scope and design of comprehensive security tests, conduct the tests, and document results within the development workflow or issue tracking system. Conduct functional testing of security features, dynamic vulnerability testing, and tests for previously reported vulnerabilities. Use additional techniques such as fuzz testing, penetration testing, and root cause analysis to strengthen security. Document all issues, remediations, and lessons learned, and use resources like source code and design records to inform ongoing test planning.

[SAMM] Fuzz testing for vulnerability detection (SSS-03-02-01-01)

Integrate fuzz testing into the development process to identify security vulnerabilities by injecting malformed or unexpected data into application inputs. Ensure testing covers all major input parameters, simulating real-world attack scenarios to detect unexpected crashes and weaknesses. Leverage automated fuzzing tools to systematically generate malformed inputs, exposing bugs that structured testing may overlook. Prioritize recording and analyzing crashes to assess their security impact, ensuring that discovered vulnerabilities are properly triaged and remediated. Use existing fuzzing frameworks to enhance test coverage and detection accuracy while minimizing manual effort. Apply fuzz testing to closed systems, such as SIP phones or embedded applications, where traditional security testing may be limited. Maintain a continuous testing strategy, incorporating lessons learned to improve resilience against unpredictable inputs.

Operations

ID Operation Description Phase Agent
SSS-03-02-01-01-01 Cover all main input parameters with fuzzing Ensure that fuzz testing covers most or all of the application's main input parameters. This includes any data that the application accepts, whether from users or integrated systems. Development Security Engineers, QA Teams
SSS-03-02-01-01-02 Send random or malformed data to the application Perform fuzz testing by sending random or malformed data inputs to the test subject in an attempt to make the application crash or behave unexpectedly. Development Security Engineers, QA Teams
SSS-03-02-01-01-03 Record and inspect crashes for security impact Record all application crashes during fuzz testing and carefully inspect each one for potential security impacts, such as data corruption, unauthorized access, or unhandled exceptions. Development Security Engineers, QA Teams
SSS-03-02-01-01-04 Automate fuzz testing using existing tools Leverage existing fuzzing tools and frameworks to automate the fuzz testing process. Utilize their supporting tooling to generate test cases and track issues efficiently. Development Security Engineers, QA Teams
SSS-03-02-01-01-05 Assess the quality of a closed system Use fuzz testing to assess the robustness of closed systems (e.g., SIP phones, proprietary systems) that might otherwise be hard to evaluate through traditional testing methods. Development Security Engineers, Testing Teams
SSS-03-02-01-01-06 Triaging crashes for vulnerability analysis After performing fuzz testing, triage any crashes to understand their root cause and determine whether they could lead to security vulnerabilities, such as buffer overflows or denial of service. Development Security Engineers, QA Teams

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-1911)
NIST Secure Software Development Framework (PW.8.2)
OWASP SAMM: Software Assurance Maturity Model( V-RT-1-B)