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.
Automation is not new to application teams. Quality Assurance (QA) has for long adopted automation as part of its test iterations. Automation scripts right 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 to 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% among Mature DevOps practice participants where the same number was at 31% 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 mature teams turn to commercial platforms, others have found success in open source and simpler models. One of the most immediate area 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% 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 for 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% responded that they have mature DevOps practices as part of their application delivery process; and 49% 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% 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 is good and well, 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 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 and making it sustainable and scalable.
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 can 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 evil/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 upto 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% 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 get the right mixture of skills between DevOps and security. The same survey indicates that seven out of 10 developers lament that their organization do not provide them the necessary trainings 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 trainings 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 to be able to work with developers to identify vulnerabilities and also offer remediation instead of just poking holes in the product.
