In order to achieve a (software delivery lifecycle) SDLC that is efficient and cost-effective, we strive to automate every step with as little human interaction as possible. We do this because the ability to hold a product to a high quality standard throughout its lifespan is essential in building a maintainable, resilient and secure solution.
This blog focuses on the tools and approaches that help us maintain a high level of code quality and application security, while remaining relatively hands-off. We look at the benefits and problems of these tools and present our recommendations about which approach to take, and when. Whilst a little technical in places for some, if you’re interested in SAST and DAST Adoption and understanding the difference this is the blog for you.
Here are four core concepts we’ll be delving into:
- Static Application Security Testing (SAST)
Can run on the development machine or have a setup in your CI/CD and can run on every code push to Git
- Interactive Application Security Testing (IAST)
Conducted post deploy and uses a combination of techniques and tools to achieve desired results. (a Security Expert ‘interacts’ with the application under test by setting up attack vectors)
- Dynamic Application Security Testing (DAST)
Tool based security testing that is used on top of functional tests to check application communication channels.
- Runtime Application Self Protection (RASP)
Production monitoring and risk assessment, which relies on tools and automated processes to counter application attacks.
SAST – Static Application Security Testing
SAST is used to identify possible improvements by analysing the source code or binaries without running the code. It is fast and you don’t need the code to be compiled so the SAST tools can be integrated directly in the IDE (Integrated Development Environment). This gives developers immediate feedback about the code they write and how they can deliver a better software product. Projects that manage to integrate SAST in their SDLC will notice immediate benefits in code quality by adhering to a more detailed DoD (Definition of Done) task completion checklist that is not required to go through a PR (Pull Request) Review.
The main benefit of SAST adoption is that developers have immediate feedback on their code and how to improve it; there is no need to deploy or compile the code.
The problem (with SAST) is that application code that is written by developers is just a small part of an application under test. In many cases, we rely on different languages, frameworks, servers that interact and many other systems that make up the ecosystem. If you are doing only static analysis you are not only ignoring application execution and infrastructure but also the communication protocols. Hackers will usually use information that is kept in cookies and requests to penetrate and exploit the system’s flaws in your infrastructure or application.
SAST Tools can be setup on the developer machines or in their IDE, but can also be setup as a CI/CD tool.
IAST – Interactive Application Security Testing
IAST relies on agent tools set inside the application at communication junction points. Tools need to be configured and each agent will gather results to a certain degree of accuracy.
“IAST is a combination of SAST and Dynamic Application Security Testing (DAST). But this security solution has still not matured to a point that it can be defined precisely or measured accurately against rivalling solutions.” – Sharon Solomon
Due to these factors, the tools might not be a fit solution to be used in production environments. The effectiveness of the tools is largely affected by the instrumentation and attack simulations.
The implication is that engineers and security professionals are responsible to set up and run an analysis of results, thus requiring specialised personnel. Agent installation inside the infrastructure might touch on other constraints set by bank rules and regulations.
DAST – Dynamic Application Security Testing
DAST is great for developers, allowing them to have rapid health checks on their code. It should be mentioned though that this often creates a false sense of safety and security, which can can be a very precarious position. Because of the nature of the systems under test, DAST can be run as a security proxy. The advantage of such an approach is that you can use your existing tests (Integration or E2E) tests and run them through the DAST proxy. On top of testing your application business flows and environment setup, you also get a nifty security report on all the requests that bounced during testing. Reports usually contain warnings for industry standard OWASP Security Threats. The security assessment can be further refined by security experts in order to achieve a more comprehensive suite of checks.
A benefit of DAST adoption is that developers or security analysts can identify sensitive information exposed by the system through analysing the requests generated by the application.
On a day to day basis, developers can analyse changes in requests and sessions contain only the desired content. Security analysts also now have a tool that can see the underbelly of all business flows so they can focus straight on attack vectors and other security aspects. Policies can be verified and enforced (e.g. GDPR adherence by identifying how user sensitive data is exposed within the application communication). Tools usually also provide warnings on standard configuration but the large array of tools require fine-tuned configurations. Some tools provide community script repositories (10) which can be directly used or customised to project needs.
The problems faced with DAST tools is that they generate a large number of warnings (and false negatives) that need to be carefully investigated by developers and security professionals alike. DAST tools require extensive configuration in order to achieve the targeted results.
DAST tools can be set up in the development infrastructure or as a CI/CD tool. Developers can use the DAST proxy tool from their local machine (by redirecting their tests through the proxy).
RASP – Responsive Application Self-Protection
ASP tools are designed to monitor running applications and intercept all communication, making sure both web and non-web applications are protected. Depending on how the tool is set up it can signal identified threats or it can take actions. RASP can stop the execution of malicious code (e.g. it identifies an SQL injection) or it can terminate a user session in order to stop attacks. The way it stops attacks is dependent on how RASP and the application under test are integrated.
There is an API based approach in which the RASP tools use the application API to steer the behavior of the application. Developers will find that through such an approach they can handle the integration with RASP tools in a very specific way (e.g. Login App might define an extended API to cope with custom decisions from the RASP tools). There is also an approach where a wrapper is set up for the app and RASP sits on top, thus giving a more general integration with an existing app.
A benefit of RASP is that is can distinguish between attacks and legitimate requests. It can limit or block access to attackers that already gained access to the application. These capabilities will not safeguard against all threats, for this reason, security specialists recommend building security mechanisms at the application level.
A drawback is that environments that use RASP can notice their performance is affected by the adoption of active scanners. User experience may be impacted by the loading latency.
Due to the nature and scope of each tool and how they fit in the SDLC, there is no single solution adoption to automate and safeguard delivery to production.
SAST is the most cost effective way of checking for code related defects and security threats, but its scope (static code) ignores the vast majority of interacting elements in a software solution.
IAST adoption is to be desired but might take more time to integrate it as a formal step into the SDLC due to the requirement of specialised resources and tooling.
DAST complements SAST by checking in the SAST blind spots (running against deployed code, checking environment configurations and communication protocols) by providing extended reports with security in mind.
Note: that DAST tools can be used as part of CI/CD processes. Since IAST and DAST are quite similar in many aspects, their capabilities are transferable.
RASP uses a combination of tools for network traffic monitoring. Due to the proactive nature of the intrusion detection systems, a set of tripwires are set (eg. honeypots) by network and security professionals that need to be monitored. The response to identified threats can be carefully handled in a time effective way.
We would recommend the use of a small set of tools and practices that make sense for your SDLC. Gradual adoption of tools and processes should always be made with development delivery in mind. SAST on its own will not safeguard against a number of threats and will signal only code related issues. Ultimately, adopting the right set of tools will help complement coverage and type checks performed on the system to the point where the code is production ready.
If you’d like more specific advice around the right tools and practices for your SDLC you can get in touch with us here.