Figure 1: Changing security precedence with evolution of IT industry
On the long road to well designed and secure applications, numbers of tools and technologies have emerged. Static application security testing (SAST) tools enabled detecting security vulnerabilities within Code, detecting defect early in root to live. Dynamic application security testing (DAST) tools enabled simulating hacker vista before code goes live. Then, IAST tools provided instrumentation on analyzing running applications. Finally, RASP tools enabled detection of live attack and self-heal with necessary measures.
Application Security Testing essentially aims to deliver secure applications by adopting a proactive and reactive approach during development and operations. Let us discuss what approach and tooling are still relevant and will suit your needs in the development/testing process considering the constant change.
Reality of point-in-time snapshot
Traditionally, legacy application developed during the waterfall era provided snapshot view of security posture. Before the advent of SAST, pen-testing was considered the holistic approach to vet security postures, however, the challenge was it just provided a point-in-time view of security. Followed by SAST and DAST, which covered, both inside-out and outside-in view. However, it again only provided a point-in-time snapshot of security posture. These approaches worked well for waterfall/agile as application security landscape was playing catch-up. However, with DevSecOps coming into play, the goals has evolved from point-in-time snapshot to continuous feedback in the areas of code level vulnerabilities, hacker vista simulation, and maximizing on automation. Further amplifying the problem, the SAST and DAST tools come with a downside of reporting false positives, which leads to increased dependency on security experts to exploit proper usage and invites manual effort to address accuracy of findings.
Possibility of continuous feedback
With the new architectural style of software development, software started getting consolidated as small services. With increasing adoption of faster development cycles and changing business needs, microservices are gaining traction in the development world. This has helped organizations to get into the market faster and serve the customer with minimum capabilities, which are modified over time to meet the full demand and work on full scale.
With microservices based deployment models, it becomes mandatory to verify the code and check for vulnerabilities with the speed of deployment cycle. Most organizations when they make the move to microservices, opt for DevOps frequent-release cycle. As a result, instead of releases occurring once or twice a year, they can happen once or twice a week—or multiple times a day. This has led to an increase in adoption of tools, which can automate and help to reduce the testing burden for security/developer teams. Moreover, microservices produces small chunks of working code in production, giving a unique and restricted functionality to the application. This creates a smaller attack surface for testing consideration and does not require entire set of services. It gives an accurate information on vulnerabilities developers can focus on rather than scrolling the entire gamut of things in a monolithic application development.
Security tooling empowered with integration onto CI/CD achieved the goals of continuous feedback in the areas of code level vulnerabilities, hacker vista simulation and maximize on automation. However, given a firm that has a mix architecture landscape i.e. both monolith and microservice or rather firms migrating from monolithic to microservices and are stuck in between, wherein applications are built on both traditional and modern architecture. This brings us to the question, “Are these approaches and tools still relevant in the DevSecOps evolutionary paradigm?” or rather “How to leverage the existing approaches and tools to achieve relevance in the DevSecOps evolutionary scale?”
Winner combo for application security testing
Vendors operating in security domain float varying combination of enterprise tools. Vendor C offers SAST +IAST, a combination of application security testing with a potential to replace DAST (SAST+ DAST). Vendors are leveraging ML algorithms to deliver better results among SAST+IAST findings. IAST adoption requires a mature outlook to application security and is unfit for the traditional way of application development, where the entire application is developed and the CI/CD pipeline is absent, the use of IAST is negligible. Organizations where developers have strong security background are skipping SAST/DAST and going straight to IAST in some selected cases. SAST insights into code level vulnerability providing provides inside-out view desired just before deploying onto QA environment. DAST comes handy to highlight outside-in view, which is desired just before moving code to production. Early testing was the ideal theme, which promoted surfacing DAST issues because it surfaces development issues early within the SDLC before it starts compounding. DAST tools, moreover, unveils vulnerabilities missed by SAST tools. Thus, SAST+DAST is still foolproof application security testing combo. Figure 2 provides a matrix of testing tools that align with different development architectures.