SAST vs DAST vs SCA vs Secrets scanning
Most DevSecOps or AppSec know the difference and could answer what each perform, but do you?
SAST stands for Static Application Security Testing.
Most SAST solutions perform scans and identifies vulnerabilities as developers code. Most of them also integrate into the integrated development environment (IDE), where it identifies security vulnerabilities and provides guidance to remediate them.
Most SAST solutions used by DevSecOps and AppSec teams today are www.snyk.io, www.checkmarx.com, www.veracode.com and others.
DAST stands for Dynamic Application Security Testing.
Most DAST is a black-box testing method, meaning it is performed from the outside in. DAST focuses mainly on exploitability of the code and application. The principle revolves around introducing faults to test code paths on an application. For instance, it can use threat data feeds to detect malicious activity.
Most DAST solutions used by DevSecOps and AppSec teams today are www.burpsuite.com, www.zaproxy.org, www.synopsys.com, www.netsparker.com, www.rapid7.com and others.
SCA stands for Software Composition Analysis, most of the time, it depends who you are talking to, people mix it with different meanings, although, this could be more confusing than the acronym.
One hint is in the word composition which can be defined as “the nature of something’s ingredients or components; the way in which a whole or mixture is made up.”
Thus, SCA == an analysis of software and all its components.
Software components can be divided into two categories:
- open-source code
or
2. proprietary source code
In today’s world, open-source is ubiquitous. In fact, up to 90% of applications are open source. Proprietary code has fallen by the wayside because of its lack of ability to keep up with the speed that open source enables.
SCA vendors are www.snyk.io, www.shiftleft.io, www.aquasec.com, and others.
Secrets Scanning is scans repositories for known types of secrets, to prevent fraudulent use of secrets that were committed accidentally.
If your project communicates with an external service, you might use a token or private key for authentication. Tokens and private keys are examples of secrets that a service provider can issue. If you check a secret into a repository, anyone who has read access to the repository can use the secret to access the external service with your privileges. Most vendors recommend that you store secrets in a dedicated, secure location outside of the repository for your project.
For example, GitHub has secret scanning option that is a paid feature, Github will scan your entire Git history on all branches present in your GitHub repository for secrets.
For example, secret scanning is available on GitHub.com in two forms:
- Secret scanning for partner patterns. Runs automatically on all public repositories. Any strings that match patterns that were provided by secret scanning partners are reported directly to the relevant partner.
- Secret scanning for advanced security. You can enable and configure additional scanning for repositories owned by organizations that use GitHub Enterprise Cloud and have a license for GitHub Advanced Security. Any strings that match patterns provided by secret scanning partners, by other service providers, or defined by your organization, are reported as alerts in the “Security” tab of repositories. If a string in a public repository matches a partner pattern, it is also reported to the partner.
Here are some of the Secrets scanning vendors most DevSecOps and AppSec folks use https://spectralops.io/, https://bluebracket.com and others.
