What’s in your tech stack? A hodge podge of open source and commercial tools, some customized automation scripts, maybe some workflow management tools that help you be ‘agile’. Whatever your selected tech stack is, it doesn’t mean you are following DevSecOps methodologies. One thing is certain with DevSecOps, the ‘Sec’ – Security should be part of every aspect of the process along with the fundamental desire to automate as much of the build, deploy, and secure process as possible. Choosing the right tools to streamline and automate really come down to organizational goals and what sort of applications your team are building and maintaining.
After your organization has an idea of the software projects its going to manage, you can begin to map out your long term organizational goals to determine how you scale and grow your applications. Does your organization want to be cloud agnostic so that you can leverage all cloud platforms as needed? Do you see a need to keep some assets on-prem and others in the cloud that have hybrid cloud components? Perhaps some of your applications are air-gapped for regulatory compliance and will never be in the public cloud. DevSecOps platforms and tools typically have features that require public internet connectivity, so having a plan for private/on-prem deployments for your tool chain should be validated.
Does your organization have a team in house that can manage complex DevSecOps platforms and tools? It’s a long list of skills and experience needed to keep things running smoothly. Site reliability engineers, Kubernetes and container expertise, Cloud Architects, Security Operations Engineers, Security Compliance Experts, DevSecOps engineers, and the list goes on. If you don’t have the right team of ninjas, it will be a challenge to win, and if you do have those unicorns, would they be more valuable in other positions that drive revenue vs managing infrastructure overhead?
Think of Agile as the methodology to help manage a team – technical or not. Having daily SCRUMs (standups) typically don’t consist of discussions on complex technical requirements and don’t lay out all of the details on how a project is being built. The focus tends to be at a higher level, includes issues, blockers, and general team communication to make sure things keep moving. Agile sprints and milestones have more detail on the objectives, features, and issues with software development. Those agile sprints could contain artifacts produced by the DevSecOps pipeline, or could be related to improving and changing the DevSecOps infrastructure pipeline but one thing is certain. DevSecOps does not equal Agile but they can be related when it comes to actions taken in Agile workflows.
In the defense world, security is priority 1 and designing software, deploying infrastructure, and managing networks all require deep insight into security risks. Every aspect of the software development lifecycle should include a security aspect that identifies and possibly blocks risky components, poor programming practices, vulnerable infrastructure, non-encrypted data, and other at risk components. The diagram below shows the stages of DevSecOps pipelines based on the DoD DevSecOps Enterprise Reference Design Architecture 1.0.
Agile processes can be part of a DevSecOps methodology but the fundamentals of DevOps or DevSecOps require additional tools, methods, and steps that are not a part of agile best practices. The desired outcomes of Agile and DevSecOps include faster deployment times to production and a higher frequency of releases. Agile methodologies can be applied to any project even if software is not involved. DevSecOps is more rigid in terms of applying it to software and infrastructure projects.
Similarties in DevSecOps and Agile methodologies help integrate organizational goals and workflows. Referencing sprints, issues, and milestones in software and infrastructure changes help track changes that go through DevSecOps pipelines. Security vulnerability concerns can be included in sprint releases and can be used to report metrics on risk that help drive production release decisions. Clearly all organizations are at risk of cyber threats and want to minimize the chances of releasing vulnerable software that could greatly damage an organization. Organizations that are part of the software supply chain, are increasingly looking for ways to minimize their security vulnerability risk.
The software industry is estimated to be a $578 billion dollar industry in 2021 with a CAGR of 7.38% through 2026. Aside from the scope of the software industry, the end-users, businesses, governments, and virtually any consumer is affected by the potential security vulnerabilities released on the market. The impact of software vulnerabilities go beyond organizational concerns and extend to national security, global markets, and individual safety.
Public cloud providers are releasing full DevOps/DevSecOps services and tools that help software builders quickly adopt software pipeline tools and deploy them to cloud provider resources. Azure DevOps, AWS DevOps, and Google Cloud all provide integrated tool sets to help developers quickly adopt DevOps pipelines and deploy to the cloud. Tools that are tightly integrated with cloud provide services certainly provide value and ease of use but typically lack capabilities to run anywhere, customize security tooling, metrics, and run in private infrastructure environments.
Organizations can offset vendor lock-in concerns by using more open source tools that can run on any cloud provider. Integrating automation and security tools that are widely adopted and possibly integrated by cloud vendor services. Using managed service providers that focus on DevSecOps integration and value added services can lower the risk of vendor lock-in and lower the risk of having specialized talent on-staff to architect and run DevSecOps pipelines.
Flexible consumption options for public, private, and on-prem environments.