Realigning Security Paradigm for Successful Devsecops in the Evolving Technology Landscape

Change has been a constant catalyst contributing towards the evolution of information technology. Market trends have been the centrifugal force driving exploitation of technology to meet growing business needs and future innovations. The change to technology landscape arise from two different stimulus, namely technology creation and technology diffusion. The former is the combination of fundamental capabilities enabled by advances in foundational science and engineering research, yielding to a new functionality. The latter is the adoption of these technologies in new products and services and their emergence in new markets over time. Historically, IT landscape has evolved in phases, namely a) Development Process b) Application Architecture c) Deployment Environment and d) Infrastructure Hosting.

Phase 1 of development process witnessed waterfall model where priority was given to development activities as market demand was for a fit-for-use product, thus security was of least priority or checkbox item. This phase had a siloed approach with the development, quality assurance, and operations teams functioning in a disjointed manner. Not to mention, security teams weren’t taken seriously considering the development priorities. Proactive defect fix was a painful activity as testing consideration were much later in the process. Finally, after 45 years of inadequacy, emerged agile manifesto, which led to Phase 2 of the evolutionary cycle for development process.

Agile was a transformative model, which was the proponent of adaptive planning, early delivery, and continuous improvement, and encouraged flexible response to change. Essentially, it was an answer to growing business demand of speeding software development processes by embracing smaller release cycles. Now software development moved from 18-month to 2-3 months cycle where customer had a working product however, security was viewed a technology prerogative. Phase 2 translated to addressing immediate business need of going to market on time. With the increasing agility from development and testing team, operations team experienced bottleneck leading to Phase 3 of evolution.

The remedy to common hold up was introducing agile process to operations and infrastructure, resulting in DevOps thus marrying development and operations activities during development process. Automated infrastructure provisioning, enabled developer to move significantly faster, rooting the application development process in an automated toolchain. Security was blamed for stalling the pace of development considering it had become a gating criterion. And until security was collaborating as part of development and operation, it would remain a bottleneck, resulting in DevSecOps.

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.

Figure 2: AST tooling combo for various development architectures

Some vendors are offering IAST along with DAST purchase, thus not selling independent IAST. This might demonstrate lower confidence in the IAST solution considering the underlying technology mechanism, which is more of an evolved-DAST, rather than an IAST. There are other vendors who offer IAST with minimal technology (3-4 language) support, as they didn’t find momentum in the solution during the launch. Although IAST vendors have experienced less traction in the past, as per Gartner, there has been 40% growth in inquiry volume since 2019, which demonstrates the curiosity in the product with the change in market mood to DevSecOps adoption. Essentially, customers are seeking AST capabilities which can bring together best of both SAST and DAST.

DAST cannot scale rapidly similar to IAST to achieve continuous testing. Thus, DAST will be viable option where frequency of test is not continuous, and is mostly point in time even with desirable shift right and left integration into development pipeline. Moreover, some DAST tools are capable of leveraging QA automation scripts or recording their own test, reducing the tester’s effort. Some of the DAST tools are providing integration for containerization as well. In addition, many strong DAST tool vendors do not have SAST offering, creating a competitive disadvantage.

Conclusion

With all types of IAST tooling options in the market, there is an ever-growing debate over the best ones to be procured and deployed. The equally varied development tools curated for specific requirements and solutions aggravates this dilemma of choosing an application security toolset. Based on our analysis from vendor datasheets and internal proof of concept, it’s suggested that current offerings in IAST are good for firms, which are heavy on microservices and require continuous security testing during development cycle. In addition, it’s advised to use DAST+SAST combo for monolith-based applications until the firm completely moves to micro services-based architecture. IAST has the capability to replace DAST in the near future, where micro services-based architecture rules the space. However, for now, SAST+DAST can be more helpful and SAST+DAST+IAST complement each other.

For more details on improving security of your software, connect with us at cybersecurity.services@wipro.com

Allam Vinodh Kumar
Practice Partner, Cybersecurity & Risk Services, Wipro

A globally recognized Cybersecurity Assurance Evangelist, Vinodh has more than 20 years of experience building, developing, and securing web-based software systems. As a Practice Partner for Cybersecurity & Risk Services at Wipro, his technology teams launch and expand critical application security initiatives and build secure applications and infrastructures, integrating security throughout the development process.

Arun Pillai
DevSecOps Architect, Cybersecurity & Risk Services, Wipro

Arun champions DevSecOps charter for Security Assurance Service within Wipro's Cybersecurity and Risk Services division. He has over 14 years of experience with specialization in the security domain. He has worked and managed projects related to Security Architecture, Secure SDLC, Threat Modelling, Secure Coding, Penetration Testing and Security Consulting.

Arun is an ISC2 Certified Information Systems Security Professional (CISSP) and ISACA's Certified in Risk and Information Systems Control (CRISC). He holds a Master's degree in Information Technology from Sikkim Manipal University of Science & Technology and is a TOGAF certified Enterprise Architect from TheOpenGroup.