DEVOPSdigest

Melding security into Development Operations is often confused with providing security to secure applications. There is a high level of relevancy to securing software and applications from the outside, but the focus of DevSecOps largely remains on the following:

1. Ensuring the code is free from vulnerabilities or exploits

2. Addressing and identifying policy constraints/needs

3. Obfuscating the code to prevent reverse engineering

Accomplishing the first identified area — vulnerability management — requires ensuring that the development process focuses on code quality. We need to identify (as early as possible) the impact of known vulnerabilities and address them through the adoption of an overall model, development of a framework to manage the process, enforcement of adopted coding standards, and training of the development teams to engage, create, and improve over time.

The second area — policy constraints — becomes a bit broader when one starts thinking about policy as it impacts the development process. It is where we introduce Software Composition Analysis (SCA) because the more we understand what goes into the application, the more we can avoid issues that create unnecessary efforts for dev teams. One such example is software licensing.

Coding elements, regardless of being open source, often include licensed artifacts with limitations concerning the number of uses, the types of applications in which they can be used, and so on. Likewise, even if licensing isn't an issue, certain artifacts might be prohibited due to branding, patent, or other concerns. If set up properly, Software Composition Analysis can provide an early warning system to identify risks and work through them, around them, or altogether avoid them. SCA also benefits the DevSecOps process by ensuring that the application security guidelines of OWASP (Open Worldwide Application Security Project) are followed.

To accomplish the third aspect of DevSecOps — code obfuscation — the development process is often joined together with a set of tools to obfuscate the code. Testing an application to ensure it is not easy to reverse engineer can be accomplished in many ways that intersect heavily with the quality engineering (QE) function of the DevOps process. Some might argue that QE is an essential part of DevSecOps, but in reality, QE and DevSecOps are vital partners engaged in a symbiotic process between Development, Security, and QE.

Whether DevSecOps tools are cloud-based or on-premises is largely irrelevant to their effectiveness provided that the tools chosen fit the environment they're meant to support. The three primary DevSecOps methodologies (keeping in mind that there are variants and alternatives) are Dynamic Application Security Testing (DAST), Static Application Security Testing (SAST), and Interactive Application Security Testing (IAST). Though there are distinct similarities and dissimilarities, all three have similar goals (secure, efficient, and quality applications), and some share the same tools. However, the three methodologies differ over the frequency and stages where testing is conducted.

Development methodology (CI-CD, Agile, etc.) largely determines which DevSecOps methodology is best suited (the shorter the deployment lifecycle is, the more important the DevSecOps becomes). Other considerations should also be taken into account, however, such as time to market, QE availability within the process, and cost. These considerations also determine which test automation tools should be selected, where they should be hosted, and who should use them. Likewise, tool integrations will have a role in determining the suitability of testing tools within the overall stack.

Succinctly articulating the real goal of DevSecOps matters a great deal. The goal of DevSecOps is fast, cost-effective, high-quality, development of secure applications. Taking that a little further, security becomes an essential partner of the DevOps function while minimizing disruption of DevOps workflows and deployment schedules, and yet enhancing design.

Training is integral to successful DevSecOps as it allows the development teams to use the tools and work within the processes to generate tickets, follow up on needed coding changes, bring transparency to the development lifecycle, and supply feedback on how to enhance it. Training should begin during the tools selection operation (or as early as methodology selection) and be delivered through an ongoing training schedule dedicated to maximizing the capabilities of the tools and the operational processes. Moreover, training should not be just a once-and-done. This is, of course, true of every part of the DevOps operation and special focus should be given to training new additions to the team as they are onboarded and before they're let loose on the applications.

Including development and security teams early in the tools and methodology selection routines will facilitate faster adoption and lower the perceived burden that can sometimes hinder the DevSecOps decision-making process. Tools should be selected carefully as the right tools facilitate good DevOps, while ill-fitting tools have the opposite effect--especially if they need to be replaced. Dev teams working under tight constraints don't need additional hurdles. They need capabilities that not only help them meet their schedules but also enhance their quality.

Without crossing too much into the Quality Engineering area, code quality has a direct impact on QE / QA schedules. With greater velocity inside the quality process comes greater velocity in the deployment process. This creates not only faster deployments but also greater observability into the Dev Lifecycle by decision makers, architects, and all the lifecycle's stakeholders.

Lifecycle observability is a key outcome of DevSecOps. It reduces error rates, provides greater assurance, reduces development costs resulting from errors, and increases efficiency by minimizing the needed lifecycle of corrections and QE resources. However, effective CI-CD management is only possible through successfully incorporating Security into DevOps. Security becomes a partner central to the Dev Organization and not merely an outside observer.

Given the importance of security to DevOps and overall application innovation, it is crucial for organizations to appropriately integrate them. It is not fundamentally a question of providing full environmental security, but one about making DevOps itself successful and secure.