Blog By: Kenneth Juhan
Date: August 12, 2026
Kenny Juhan will explain Software assurance in the following blog.
Software Assurance for SecurityX: SAST, DAST, IAST, RASP, SCA, and SBoMs
Modern applications are built from custom code, open-source libraries, APIs, frameworks, and third-party components. That means application security cannot depend on a single vulnerability scan before release.
SecurityX candidates should understand several software assurance technologies, including SAST, DAST, IAST, RASP, vulnerability analysis, SCA, SBoMs, and formal methods.
SAST
Static Application Security Testing (SAST) analyzes application code without executing the application.
Think:
SAST = See the source
SAST can identify insecure coding patterns earlier in development.
Because it can be integrated into development workflows, SAST supports the idea of finding security problems before software reaches production.
DAST
Dynamic Application Security Testing (DAST) tests a running application from the outside.
Think:
DAST = Attack the running application
DAST does not necessarily need access to source code. Instead, it interacts with the application and looks for security weaknesses in its behavior.
The major exam distinction is:
SAST = Not running
DAST = Running
IAST
Interactive Application Security Testing (IAST) combines aspects of testing with instrumentation inside the running application.
This can provide more context about how application code behaves while tests are being performed.
Think:
IAST = Inside while running
RASP
Runtime Application Self-Protection (RASP) operates within or alongside an application during runtime and can detect or block malicious activity.
Think:
RASP = Runtime protection
Unlike SAST or DAST, which primarily help identify vulnerabilities, RASP is focused on protecting the application while it operates.
Vulnerability Analysis
Software vulnerability analysis identifies weaknesses that could be exploited.
Results should be prioritized based on severity, exploitability, application exposure, business importance, and other risk factors.
Finding vulnerabilities is only the beginning. Organizations should remediate and then validate that corrections worked.
Software Composition Analysis
Most modern applications contain third-party and open-source components.
Software Composition Analysis (SCA) identifies those components and can identify known vulnerabilities, outdated libraries, or licensing concerns.
Think:
SCA = What’s inside my software?
Software Bill of Materials
A Software Bill of Materials (SBoM) provides an inventory of software components.
A useful analogy is an ingredient list on food packaging.
Think:
SBoM = Software ingredient list
If a major vulnerability is discovered in a library, an SBoM can help organizations determine which applications contain that component.
Formal Methods
Formal methods use mathematical techniques to specify or verify software and system behavior.
They can provide very strong assurance but may require significant expertise, time, and cost.
Because of this, formal methods are more likely to be used where very high assurance is required.
Why This Matters for SecurityX
Remember the relationships:
SAST = Analyze code without running it
DAST = Test the running application
IAST = Analyze from inside while it runs
RASP = Protect during runtime
SCA = Identify third-party components
SBoM = Inventory those components
SecurityX questions often give you a specific software-development problem and ask for the BEST testing or assurance method.
Instead of memorizing only the acronyms, ask:
Do I need to inspect the code, test the running application, protect it during runtime, or understand its components?
Once you can answer that question, choosing the correct SecurityX software-assurance technology becomes much easier.
Leave a comment