Technical assessment of an application code and processes against the four levels of application security verification for applications.

Review code and applications in use for any publicly disclosed computer security flaws.

Technical assessment of the percentage of your application code that has been tested through automated, repeatable tests.

Code quality analysis applies defined rules to inspect your code for security, performance, design, and other issues. Code quality determines code that is good (high quality) and code that is bad (low quality). While code quality is subjective, the minimum standard is not, nor is the requirement that code be assessed and the findings categorized, prioritized, and disclosed.

Document the licensing model and expected disclosures associated to components in use, including open source (OSS). 

A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open-source and commercial software components. The SBOM describes the components in a product. It is analogous to a list of ingredients on food packaging: where you might consult a lable to avoid foods that may cause allergies, SBOMs can help organizations or persons avoid consumption of software that could harm them.

Software composition analysis is a process that can determine all underlying components of software and identify at least the public known (open-source) components. A well-defined process is consistent, automated, and measurable. This analysis provides visibility into components and libraries being incorporated into the software that development teams create.

Static application security testing (SAST) is a way to perform automated testing and analysis of a program's source code without executing it to catch security vulnerabilities early in the software development cycle. Also referred to as static analysis, SAST is the process of parsing through the code to look at how it was written, checkig for security vulnerabilities and safety concerns. (It is a version of white-box testing.)

Contrary to what the title may seem, this integration is with respect to roles and governance for the SSDLC process. AD would be used to verify/validate code reviews happen, by the appropriate parties and number of individuals, comments, approver validation and release sign-off in context of job title and separation of duties, individual contributors NOT being managers or only product owners, etc.

Analysis of endpoints or ports in the context of searching for an anomaly or other need for management. Potentially a better fit for integrating with an existing provider, such as Azure/Intune. Requested in the context of remediation of an exploited vulnerability.

For the aspects of the SSDLC which are not yet available in an automated fashion, these will be prompts or opportunities for integration with other tools or imported flat files.

Analysis of specified log files or feeds in the context of searching for a given phrase, keyword, or potentially a component name or identifier. Requested in the context of remediation of an exploited vulnerability.