One of the biggest reasons for adoption of the DevOps practices is speed. The digital age has ushered in a race wherein businesses that fail to deliver fast, tend to falter at the goal post. And technology plays big part in how businesses adapt faster to the market needs.
Traditionally, developers tend to prioritize functional requirements over security concerns while building applications, leaving it to operations. Including security measures when developing code, adds time and effort to a release cycle. Or that is how it is perceived. This line of thinking leads to a more ‘reactive’ approach to handling security threats rather than a ‘proactive’ approach.
DevOps is all about building great software with better speed. So mixing it with software security might look like hitting a speed breaker. “Wouldn’t adding an extra layer of work make things slower?” – “One could always run some patches and fix security loopholes later.”
Enterprises typically have a vulnerability assessment process to identify security threats and loopholes in the software. This is done at specific intervals, which could be weekly, monthly or even yearly, in certain cases. The software security team conducts defined tests, look for loopholes and work on fixing them. Best practice demands independent audit of security in operations phase of the software.
But what if, one builds security tests right within the automated DevOps framework. Instead of scheduling security checks – they keep running in an auto initiated fashion and prevent vulnerabilities before they reach production. This is the primary idea behind DevSecOps or Developer-Security-Operations.
Speed Need Not Be Compromised
Slower release cycles can be expensive for any organization. DevSecOps practices ensure that speed is not compromised for security. Security testing techniques such as Fuzz Testing and Penetration Testing can be automated and included before the code reaches production. Fuzz Testing or Fuzzing throws a massive amount of random data into the system to check how well it can handle threats that could bring it down (DDoS attacks, for example). Penetration-testing checks for gaps in IAM that might allow access to unauthorized parties.
Continuous Integration platforms can also run certain security analysis tools to check for vulnerable code. These issues, if caught early on, are easier to fix than weeks later when the developers have moved on to a different release cycle.
Open Source: A Reason For Concern?
Extensive use of open source components in software development has added another layer of security vulnerability. Organizations cannot rely solely on developers to take the call when choosing open source components. The flexibility and diversity of software tools available to the development teams make them choose whatever tech that is deemed appropriate. This hegemony leads to a significant amount of complexity and could introduce unexpected vulnerabilities…
This mix and match also opens up a whole new array of weak spots that organizations and developers might overlook. However, there are tools available that can help organizations navigate this
Sonatype, a Newt Global partner, offers a whole set of products that can help organization relying of open source software components ensure that vulnerabilities and software complexities are kept in check. Their products like Nexus Lifecycle and Nexus Firewall ensure only high quality open source components make it to your software!
Committed to DevOps, but not happy with the way software security is handled in your organization? Be safer than be sorry for being faster – our expert consultants would be happy to help.
ABOUT THE AUTHOR
MADHAVAN SRINIVASAN
Managing Director – Products and Solutions