In security testing, much like most things technical there are two very contrary methods, Dynamic Application Security Testing or DAST and Static Application Security Testing or SAST.
Dynamic testing relying on a black-box external approach, attacking the application in it’s running state as a regular malicious attacker would.
Static testing is more white-box looking at the source-code of the application for potential flaws.
Personally, I don’t see them as ‘vs’ each other, but more like they compliment each other – it’s easy to have SAST tests as part of your CI/CD pipeline with tools like Code Climate.
DAST – Dynamic Application Security Testing
There are also pros and cons for each methodology, with DAST you aren’t bound to any particular technology or language – but on the downside, you are also limited to the parts of the application visible to the outside World.
An example of such a tool would be:
It’s always good to simulate attacks from the outside with the kind of access a real World attacker would have, but it doesn’t give you full visibility of the potentials flaws in your system.
SAST – Static Application Security Testing
For SAST a big con is the toolset you are using needs to be language and even framework specific, for example tools we’ve mentioned before such as:
The upside to this is that you get full oversight of the app, libraries, dependencies and parts not visible to the outside World.
IAST – Interactive Application Security Testing
There is actually a combination of the two, a form of ‘greybox’ testing that combines the DAST approach with the the SAST tooling by installing a sensor into the application itself.
A great example of this is Acunetix AcuSensor which is installed on the back-end and relays information during the DAST testing phase (so it acts as a whitebox DAST component).
You can read more in depth about this subject here: