The Three Pillars of DevSecOps
The Three Pillars of DevSecOps
Want to learn more about the recent developments in DevSecOps? Click here to learn more about test automation, threat modeling, and skill enhancement in app security.
Join the DZone community and get the full member experience.Join For Free
Going by the largely accepted definition in the industry, integrating security at strategic points in the Agile SDLC with the use of DevOps to enable a transparent and collaborative process is what DevSecOps is all about. This will be nearly impossible to achieve in today’s scenario without adopting what we believe are a few core elements, or the pillars of DevSecOps.
Test Automation — Tooling and Beyond
Automation is not new to application teams. Quality Assurance (QA) calls for long-adopted automation as part of its test iterations. Automation scripts — from Unit Testing, all the way to complex regressions — have been around for a long time. Ironically though, this known concept has, until recently, boxed functional and performance tests.
"Traditionally, most product teams do perform a customary penetration test prior to production or during their QA Test cycles, which is reflected in the DevSecOps Realities and Opportunities survey with the highest number of responses for "During QA/Test" at 67 percent among mature DevOps practice participants where the same number was at 31 percent for those with no DevOps practice".
With DevSecOps advocating a “Shift Left” approach to software security, (product engineering) teams have started to scout for feasible opportunities to tie in application security through automation. While larger and more mature teams turn to commercial platforms, others have found success in open source and simpler models. One of the most immediate areas to plug in automation to the development cycle is at the code level. Static Code platforms (SAST) have matured immensely over the past 3-5 years, making it almost seamless for a developer or a release engineer to have snippets of code scanned almost in tandem to the development cycle. Certain platforms even allow parts of code to be scanned for vulnerabilities in isolation as the code is being developed, while almost all commercial (and popular open source) SAST platforms have plugins to popular Continuous Integration (CI) tools, such as Jenkins, for scans to be included as part of the build process. The same is with Source Composition Analysis (SCA) platforms.
"Few teams choose to engage in the development phase by automating SAST/SCA scans as part of their product development. And, fewer still when it comes to design phase."
Furthermore, the survey itself observes that highly mature DevOps practices are 338 percent more likely to integrate security across the SDLC.
Run-time security (DAST) platforms have also geared up to ride the automation wave. Tools, such as ZAP and Burp, are pretty much the usual suspects in any security engineers chest of dynamic tools, and these have long supported integrations with CI services. However, not all teams have taken to automated DAST scans, at least in the initial stages of the automation journey. Unlike SAST integration, DAST automation isn’t usually a simple plug-and-play. Since the nature of a DAST scan is time consuming, teams seldom include automated DASTs as part of the daily builds. The alternative to this approach is to have DAST scans run as part of weekly or bi-weekly runs, or to configure DASTs to run scans using optimum scan policies in accordance to the context of the deployment pipe. Another approach could be to integrate QA walkthrough scripts as part of the scans to help focus on areas that are critical or need an increased coverage.
For instance, the 2018 DevSecOps Community survey observes that among 2076 participants, 25 percent responded that they have mature DevOps practices as part of their application delivery process; and 49 percent alluded to an improving state of maturity when it comes to their DevOps practices. This indicates that the automation and efficiencies brought by mature DevOps practices can be further augmented with application security automation, thus, putting the security in DevSecOps.
"Product teams that realize the importance of security in their DevOps also invest more in application security automation. A comparative analysis of mature DevOps practitioners and their investment in automated security, show a 15 percent increase between last year and this year."
One of the other factors that drives teams to adopt security automation is the need for adherence to regulations. For instance, recent revisions to compliances, like PCI, SOC, and HIPAA, has stoked interest among organizations to build security automation as part of their SDLC.
While all this appears to be good news, in reality, product teams still list security automation or the lack thereof, as one of the biggest challenges when it comes to DevSecOps and its implementation. Based on the statistics, adoption of DevOps and CI/CD implementations are significant, but it has not yet reached critical mass. With newer technologies, like cloud computing infrastructure and application container software, product teams can release software with greater agility, making it sustainable and scalable.
Threat Modeling — A Shift in Perspective
A lot has been spoken on the need to include agility in security testing of application in the context of DevSecOps. However, whether DevSecOps or not, the cost of bug while “in code” is higher than while in a prototype. While efforts are far and wide in re-calibrating security testing within the context of Agile, teams have a long way to go in bringing in threat modeling under the umbrella of AppSec in DevOps.
To be fair to application and security teams, threat modeling, even in the age of Waterfall, has largely been a rarity. Therefore, the task to scale up an activity, such as threat modeling attune to the speed of Agile, is an incredible task.
The secret, however, lies in the approach to threat modeling. The activity is to be transformed into a process of deriving security test cases (which it ought to be) rather than a disjoint effort of unearthing a “type” of security flaw. This would enable teams to actually adopt threat modeling as a part of the product development process. Another point of integration could be in tagging user stories and associated abuser stories right within the project management/functional specification management platform, such as Confluence or Google Projects.
Threat modeling is, and should be, one of the first activities that product teams come together to incorporate application security, as soon as the requirements have been made available. This activity happens during the design phase in conjunction with design/architecture review. Being a team activity, this would help in collectively visualizing the various threats an application stands to face, if and when released to market, and also how they can be mitigated, transferred, ignored, or accepted, depending on business priorities. Ideally, with every sprint, product teams should come together to review their features/user stories and come up with abuser stories that can be considered as non-functional requirements with clearly stated acceptance criteria.
With the growing demand for DevOps and the need to create scalable, secure, and reliable software, product teams have challenges in recruiting the right people with the right skills.
The challenge is twofold. The first problem is finding employees with the balanced combination of technical acumen and solid interpersonal skills needed to support a fast-paced and collaborative continuous delivery environment. The second is even more daunting — finding employees of that mold who also have the grounding in security principles and tooling necessary to deliver both continuously and securely.
"Studies show that by 2022, the application security market is to be valued at USD $9.0 billion, and on the other hand, a shortage in workforce up to 1.8 million by the same timeframe."
This is one of the fundamental stumbling blocks impeding IT’s evolution to DevSecOps. While academic institutions do offer professional courses specialized in computer science or information technology, there is a gap in the curriculum offered and the expectations of organizations when it comes to security. So much so that, as indicated in DevSecOps Global Skills survey, 70 percent of the respondents feel that their curriculum lacked for the positions that they are currently engaged in. While most courses focus on application development, the courses themselves are not tuned to meet the needs of application security of a fast-paced software firm in today’s scenario.
In this scenario, it is a task for the industry as a whole to come up with short and medium-term steps to fill the gaps in skill enablement by ensuring that their workforce gets the right mixture of skills between DevOps and security. The same survey indicates that seven out of 10 developers lament that their organization does not provide them the necessary training in application security for their current positions. The survey further goes on to allude that even top-rated application security programs do not fill seats, as companies are unwilling to release developers days together as it affects their development priorities. The cost and time involved in attending training that would attract organizations irrespective of their size. In order to achieve success and maturity in DevSecOps, product teams must look into developing cross-functional skills where QA engineers can expand on their functional automation skills by extending it to security automation using open source frameworks. And, similarly, security engineers learning to understand code need to be able to work with developers to identify vulnerabilities and offer remediation, instead of just poking holes in the product.
Published at DZone with permission of Rahul Raghavan , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.