SAST, DAST, IAST, SCA … confused about the differences? We thought it might be helpful to clear things up by using the analogy of human health. When you visit the doctor with an ailment, or even for a routine checkup, you are likely to undergo a series of tests to find potential health conditions or diseases. Since the tests are targeting different parts of the mind or body, the results may vary. So, the more tests performed, the better the chances of discovering and treating an illness. The same logic applies to security health. The more application security tests performed, the better the odds are that you will find and remediate security flaws or vulnerabilities.
Now that we understand the importance of the application security tests, and we know that they are looking for different vulnerabilities and flaws, how can we distinguish between them? We will continue with the human health analogy, comparing AppSec tests to common, easy-to-understand health tests.
Make no bones about it, static analysis is very similar to an X-ray. Just like X-rays, which produce a static image to find torn and broken bones, static analysis evaluates an application from the inside out, reviewing stationary code for security vulnerabilities. By catching the vulnerabilities before running the application, developers can fix flaws in a timely, cost-efficient manner.
Dynamic analysis is comparable to a reflex test. During a reflex test, the doctor taps a tendon to make sure that the patient’s motor and sensory skills are intact. Dynamic analysis leverages a similar outside-in approach, poking and prodding at the running application to analyze vulnerabilities.
Software composition analysis
For software composition analysis (SCA), you can think of a dental exam. During a dental exam, if you have cavities, your fillings are inspected. Although fillings are not an organic part of the body, if undetected and untreated, faulty dental fillings can lead to serious illness. This concept is a lot like software composition analysis. SCA inspects open source code for vulnerabilities. This is code that you didn't write yourself, but it's still affects the security and the health of the application. Despite the fact that open source is a third-party component, if vulnerabilities go undetected, it is nothing to smile about.
Interactive analysis can best be compared to an Electrocardiography (EKG) exam. An EKG is when a doctor puts electrodes on your chest to measure your heart rate. The doctor might have you exercise while conducting the EKG to evaluate your heart under stress. With interactive analysis, you place an agent in the runtime environment and put the application under load. From there, you can see what vulnerabilities the agent discovers.
A penetration test is the equivalent of a doctor’s personal assessment. When you visit the doctor and convey your symptoms, the doctor uses their expertise to provide a diagnosis. It is not unusual for the doctor to pick up on an illness that is undetectable by an exam. Similarly, with a penetration exam, an expert penetration tester simulates a security attack on the application to find vulnerabilities often undetectable by other, more automated methods.
So, the next time you visit the doctor and undergo several tests, remember that each test holds a purpose. And when it is time to evaluate your AppSec program, remember that the same logic holds true. The more security tests you are able to perform, the better the chances of catching vulnerabilities.
Get more details on the strengths and weaknesses of the different AppSec testing types in our recent guide, Application Security Best Practices vs. Practicalities: What to Strive for and Where to Start.