This is a pretty broad question that covers a number of application levels and environments so there isn't necessarily a one-size-fits-all answer. (Then again, when it comes to app security, there probably never is).
The definite starting point is static code analysis or application security software tools to scan your source code for potential security vulnerabilities and provide feedback on how to remediate them. They can be integrated into your development pipeline to catch issues early in the process, both enforcing and validating policies that you configure.
Infrastructure as code tools (Red Hat Enterprise Linux, HashiCorp Terraform, for example) enable you to define your infrastructure in code and manage it through version control. That way, you validate that your infrastructure meets security requirements before it is deployed and ensure that changes to the infrastructure are properly audited.
Another (likely) necessity on the cloud side is a cloud security posture management (CSPM) tool to monitor your cloud infrastructure for security risks and provide recommendations for remediation.
If your environment includes containerization, container security tools scan your container images for vulnerabilities and provide recommendations for fixes. Integrating container security tools into your CI/CD pipeline can help ensure your containers are secure before they are deployed.
Basically, you're going to need tools at each level if you're going to validate and enforce app security requirements consistently and reliably, and if you have any thoughts of scaling things.
Director, Middle East, East India & SAARC at DMX Technologies
Dec 16, 2021
Unlike dynamic application security testing (DAST) tools for black-box testing of application functionality, SAST tools focus on the code content of the application, white-box testing. A SAST tool scans the source code of applications and their components to identify potential security vulnerabilities in their software and architecture. Static analysis tools can detect an estimated 50% of existing security vulnerabilities.
In SDLC, SAST is performed early in the development process and at the code level, and also when all pieces of code and components are put together in a consistent testing environment. SAST is also used for software quality assurance. even if the many resulting false-positive impede its adoption by developers.
SAST tools are integrated into the development process to help development teams as they are primarily focusing on developing and delivering software respecting requested specifications. SAST tools, like other security tools, focus on reducing the risk of downtime of applications or that private information stored in applications will not be compromised.
SCA: Software composition analysis (SCA) products analyze homegrown applications, generally during the development process, to detect embedded open-source software (OSS) and, sometimes, commercial off-the-shelf components. SCA tools typically identify known vulnerabilities in these packages. They may also determine the license used to distribute a particular software package in order to support the assessment of legal risks. Given supply chain concerns, buyers have begun to seek SCA tools that provide indicators of operational risk, such as slow or poor maintenance, questionable project viability and multiple other factors. Infrequently, tools may generate or consume standardized software bill of materials (SBOM) artifacts.
Choosing the right static analysis software requires multiple components:
1. What are my business requirements and do I have champion BUs
2. What does your application portfolio look like (Lang. developed, Line of Code, etc.) and do we have a complete application inventory.
3. Who will manage the software and do they have the skillset (be honest, most teams ASSUME they do)
4. Next have a Proof Of Value with well defined POV success criteria that you've gathered from the BUs.
5. When looking at a Static Code Analysis software vendor, you may want to scope what Software Composition Analysis they integrate with as well. Over the past few years this has been highly critical part of AppSec programs. For instance, Veracode has their product SourceClear...CheckMarx previously integrated with WhiteSource, but that relationship ended. Synopsys has been working on their integration with Coverity and BlackDuck. Finally Fortify takes the vendor neutral approach and has integrations with BlackDuck, WhiteSource and Snyk where the plugins are open source and maintained by the vendor. Fortify's integration with SonaType takes it a bit deeper to validate if and where the 3rd party/open source code is instantiated within your code.
Key takeaway, many organizations will use 1 or more Static Code Analysis vendors to meet the business' needs. If you need a unified dashboard reporting for them all look at Saltworks Security Saltminer or contact me (Shameless plug)