Safe development: SAST, DAST, IAST and RASP
According to statistics, 90% of security incidents occur as a result of the use of known software errors by attackers. Naturally, the elimination of vulnerabilities at the stage of software development significantly reduces information security risks.
To do this, to help developers, a number of technologies have been created that make it possible to identify security flaws at an early stage, getting rid of them before the product is released. These technologies include:
SAST and DAST
SAST (Static Application Security Testing) – White box testing, has been around for over ten years. Allows developers to find security vulnerabilities in application source code early in the software development lifecycle. SAST also ensures compliance with coding guidelines and standards without actually executing the underlying code.
DAST (Dynamic Application Security Testing) – Black box testing, can detect vulnerabilities and weaknesses in a running application, usually web applications. It does this by using application error injection techniques, such as passing malicious data into software, to detect common security vulnerabilities such as SQL injection and cross-site scripting.
DAST can also shed light on runtime issues such as:
- server authentication and configuration issues
- flaws visible only when a known user logs in
This cannot be detected using statistical analysis.
SAST and DAST are often used in tandem because:
- SAST will not detect runtime errors
- DAST will not flag encoding errors, at least until the line number of the code
SAST works well when it comes to detecting an error in a line of code, such as weak random number generation, but is usually not very effective at detecting flaws in the data stream. In addition, SAST solutions are known for a large number of false positive or false negative results.
Some success in reducing or eliminating false positives has been achieved through the so-called abstract interpretation. However, for the best results, abstract interpretation algorithms should be adapted to:
- codes that use the application domain that includes its architecture
- ways to use certain numerical algorithms
- the types of data structures it manipulates
Despite all the shortcomings of SAST, it remains a favorite among development teams to this day.
The main selection criterion is the ability to scan the project at the code level.
This allows deficiencies to be found early in the product development process, which helps reduce the cost of correcting them.
What’s more, SAST can be automated and seamlessly integrated into your project workflow. This removes some of the issues typically associated with security testing of applications. This feature is in stark contrast to DAST, where large projects will have to create a separate infrastructure, run custom tests, and run multiple instances of the application in parallel with different input data.
On the other hand, DAST understands arguments and function calls, which cannot be said about SAST.
IAST (Interactive Application Security Testing) – Interactive application security testing. SAST and DAST are relatively old technologies, so it is believed that they are not the best choice for testing modern:
- Web applications
- Mobile applications
For example, SAST does not work well with:
And all this is present in almost every modern application.
Static tools only see the application source code that they can follow. Moreover, libraries and third-party components often cause static tools to freeze, generating messages:
- “Lost sources”
- “Lost sinks”
Likewise with frameworks. The static tool will not detect anything wrong with:
- web service
- REST endpoint
This is because he cannot understand their structure.
IAST is designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST performs all analysis in real time:
- anywhere in the IDE development process
- continuous integrated environment
- production environment
Since IAST works inside the application, it can analyze:
- application code
- data streams
- HTTP requests and responses
- libraries, frameworks and other components
- internal connection information
Compared to SAST or DAST, having access to all of this information allows the IAST engine to:
- cover more code
- give more accurate results
- check a wider range of safety rules
RASP (Run-time Application Security Protection) – protection of application security at runtime. Like IAST, it works inside the application, but it is more of a security tool, not testing. It connects to the application or its runtime and can monitor the execution of the application. This allows RASP to protect the application even if network perimeter defenses are compromised and applications contain security vulnerabilities.
RASP enables an application to conduct continuous security checks and respond to attacks in real time, terminating the attacker’s session and alerting defenders of the attack.
Disadvantages of RASP
The main problem with RASP is that it can give the development team a false sense of security. Some security measures can be ignored for the reason – “If we miss something, RASP will fix it.”
Another disadvantage of RASP technology is the degradation of application performance. IAST has the same disadvantage. Despite the fact that with technology accelerators it is possible to minimize performance degradation, an unpleasant residue still remains.
All of the above technologies have their own advantages and disadvantages, so their combination with each other will provide a higher level of security. However, the use of even one technology at the early stages of development allows you to create safer software, and most importantly, do it faster and at lower costs than tying all tests already faced with a problem at a later stage.