Types of Security Testing in Technical Assessment and Due Diligence: SCA vs SAST vs DAST

This post is also available as a podcast on Spotify and Youtube

Imagine you’re tasked with assessing the structural integrity of a building that has already been built or is still in the process of construction. The challenge is to ensure that the building is safe, the materials are reliable, and the construction process follows safety regulations, all while minimizing the risk of disruption. This analogy is quite similar to the world of technical assessment and due diligence, where different types of security tests play crucial roles in ensuring the safety and robustness of a product or system.

Intrusive vs. Non-Intrusive Testing

The difference between intrusive and non-intrusive testing is like deciding whether your building inspectors should only observe or actively make changes.

• Non-Intrusive Testing (SCA, SAST, Passive DAST) doesn’t interfere with the operations of the system—just like inspectors who check blueprints or monitor the building without touching anything.
• Intrusive Testing (Active DAST) goes further by probing the system aggressively, potentially disrupting services to uncover vulnerabilities, much like an inspector knocking down a wall to see if it was built properly.

While riskier, intrusive testing often provides deeper insights into potential structural weaknesses and can be used to verify potential threats or to mark them as false positives.

Software Composition Analysis (SCA): Building Material Inspection

The first step is to assess the raw materials being used in the construction—this is where Software Composition Analysis (SCA) comes in. SCA tests are like inspecting the materials being used in a building:

• Are the bricks sturdy?
• Is the cement high quality?

This type of testing looks at the open-source components and third-party libraries within your software. It ensures that none of the materials (i.e., external dependencies) have vulnerabilities or are outdated, which could compromise the security of the entire structure.

Just as bad building materials can result in a weak structure, outdated or insecure libraries in a codebase can introduce significant risks, making SCA essential for verifying that the foundation of your software is sound and up to modern security standards.

Static Application Security Testing (SAST): Reviewing the Blueprint and Construction Procedures

Next, we take a look at the blueprints and the plans behind the construction, inspecting them before or during the building process. This is similar to Static Application Security Testing (SAST).

In SAST, the source code of the application is analyzed—it’s like reviewing the architect’s plans or watching over the construction techniques being used. SAST aims to identify potential weaknesses in the code structure, like:

• Poor coding practices
• Insecure design patterns
• Areas where errors might creep in unnoticed

By catching issues early in the blueprint (or code) review, SAST ensures that potential weaknesses are addressed before they are built into the system, much like ensuring that construction workers aren’t cutting corners with structural supports or ignoring fire safety measures.

Passive Dynamic Application Security Testing (DAST): Semi-Intrusive Inspection

Now imagine the building is nearly complete, and you want inspectors to come in and assess the structure—but without causing disruption. These inspectors walk through the building, looking for cracks in the walls, faulty wiring, or areas where security might be at risk, all without actively altering the building. You need a completed building though (running system) but you don’t need access to blueprints and plans (source code).

This is how Passive Dynamic Application Security Testing (DAST) works. Passive DAST assesses the live application while it’s running but doesn’t interact with it in ways that could disrupt services. It observes and detects issues like:

• Weak configurations
• Exposed entry points

All without directly influencing the system. It’s like sending someone to observe the building under normal operations, identifying potential flaws without changing the state of the system.

Worst case scenario in a real-world software situation is, those inspectors can cause the system to run slower, as they take some of the server’s resources.

Active Dynamic Application Security Testing (DAST): Intrusive Inspection

Sometimes, you need to send in a more assertive inspector, one who will check not just how the building looks but might even knock down a weak wall or intentionally short-circuit a wire to see how the building reacts. Active DAST is a more hands-on approach.

Unlike passive DAST, it actively interacts with the system, probing for vulnerabilities by executing tests and scenarios that mimic real-world attacks. This could involve making changes to the system, introducing intentional stress, or even causing damage—just to see if and where the building (or system) breaks.

To run an active DAST, you need a completed building either the real one or a version identical to it (Staging environment) but you can allow external testers to run it for you, as you don’t need to give them access to the source code.

Summary

Each of these tests plays an essential role in assessing and securing a product or system during technical assessments and due diligence. Together, they ensure that both the materials and the final structure are robust, secure, and capable of withstanding external pressures, much like a well-built building.

Did you know?

Codenteam AI gives you all needed information around risks in SCA, SAST, DAST in the report page, you can discuss with the AI bot why it has marked each.