DevOps adoption is gathering rapid momentum, shaped by the ‘lingering’ experience of the pandemic. The annual global GitLab survey finds that for the first time DevOps teams are serious about its practice and are focusing on specific objectives to accelerate adoption. This has resulted in 60% of respondents releasing codes 2x faster than pre-pandemic rates, a 25% increase from 2020.
But releasing at speed and scale is hazardous if security is not tightly integrated into systems which not only increases vulnerability but more importantly, increases the cost of repairing. However, security integration continues to elude organizations with only 22% of the surveyed respondents having deep security integration according to State of the Art DevOps Report by Puppet, CircleCI and Splunk.
Organizations have understood the importance of security automation in release but they struggle to implement it. The question that begs an answer is why is it difficult to embed security practices in DevOps. The answer lies buried in the quest for commercial considerations which rewards speed in delivery with scant regards for security implications. Where feature delivery is a priority, security takes a back seat and becomes an afterthought—it is deemed an unnecessary loop which delays release, a small issue which can be fixed once the feature is delivered but is never resolved, unless there is an event.
Our experience also finds other issues holding up deeper security integration which primarily emanates from uninformed thought processes. It is worth taking a look into these issues as there is lack of clarity about what comprises DevSecOps practices. Below we explore few myths based on our experience and deep understanding of security issues.
The practice of moving testing earlier in the development cycle does not automatically result in sound security practices unless it is accompanied by changes such as robust cross-team collaboration which empowers delivery teams to autonomously discover, prevent and remediate security issues. One of the basic approaches we take while implementing DevSecOps projects is to pull down knowledge silos by increasing awareness and facilitating collaboration between teams to identify security issues and establish measures to counter it.
A critical activity in cross-team collaboration is threat modelling wherein members from development, security, business teams brainstorm to identify potential threats and discuss measures to mitigate risks. Teams freely discuss threats, impact and trade-offs which results in better application design.
There is a lot of confusion about Agile and DevSecOps—myths range from both being the same thing to taking a position of one versus the other. The truth lies in between—Agile and DevSecOps are complimentary practices that facilitate continuous improvements by emphasizing collaboration.
Agile development is a mindset to create the best product in the shortest time in a flexible manner honed with multiple tests. While DevSecOps objectives are similar, it seeks to build safety into the methods by integrating security at every stage of the development cycle—Agile is the foundation while DevSecOps ensures release processes are agile, safer and more secure.
Moving security processes up the development chain often causes heartburn amongst developers of increasing the workload with quality assurance and security. However, developers do not manually intervene as security processes are fully automated with specific types of tooling that automate the process without additional effort on the part of the developer.
We have implemented DevSecOps projects and empowered development teams with advanced tools to scan security, visualize and detect vulnerabilities and work as nimble teams to release functionality quicker. It does not mean roles and responsibilities of quality and security go away but developers work in conjunction to set up a pipeline with tools to do the heavy lifting.
If security processes are not baked into the CICD pipeline, cracks show up during high pressure and organizations give priority to feature release over security requirements. Often security processes are imperative, adopted on an-ad hoc basis to fulfill immediate objectives and ignored once the need has been met. To avoid this, we advise customers to make security processes declarative and automate the system using a CICD pipeline.
We have enabled customers to automate the entire development and operations environment to scan and test including unit testing of application code, source control repositories, container registries, CICD pipeline, APIs, release management and application performance after release. New Cloud-native technologies like containers and microservices are a major part of DevOps initiatives and security practices must also adapt to embrace these technologies.
At the same time, it is important to incorporate a robust monitoring and log tracking solution to ensure full compliance with the declarative processes. However, being compliant is not the same as being secure as compliance only meets business needs and does not address actual threats. For example, a policy to fix vulnerability within 60 days may well provide a window to the attacker and therefore policies must be reviewed periodically.
Embedding security practices within a DevOps culture has positive outcomes for software development—it enables code delivery on demand, and boosts developer confidence in security practices. More importantly, it helps to establish security as a shared responsibility amongst everyone in software delivery and people are diligent about issues and willing to halt deployment if a situation arises.
For long, security has been viewed as an inhibitor to software development but with an array of advanced tools available, our experience finds that security is actually an enabler to unleash high quality codes at speed.
If you want to know more about embedding security practices in DevOps, write to us at email@example.com or call us at 91 9654524072.