maxkabakov - Fotolia
Implement a DevSecOps pipeline to boost releases' security posture
Break security out of its silo, and get the whole team on board to create a culture of quality with the right tools at the right time -- and stop blindly rushing to release.
Every IT professional knows crunch time: Development is complete, the code works and everything looks good. Marketing is ready with the media blitz. Customers can't wait to get their hands on features and will deliver good feedback. The release date is a week away.
The only step remaining is to get the security group to scan the application and give approval. Cross your fingers and hope you get the green light. If security finds a vulnerability or defect, it's too late to fix it and still release on schedule.
The business must decide whether to release with a known security issue or postpone delivery. If the release goes out anyway, the security audit at the end of the development cycle meant nothing. Conversely, if security has enough clout to halt the release, we throw all our work to coordinate this release out the window, putting everything behind schedule. Rest assured, everyone will want to blame someone -- security as the bearers of bad news, testers for failure to find the problem sooner or developers for not writing secure code.
DevSecOps promises to do away with that roll of the dice at the end of production. Yet it's difficult for an organization to implement a DevSecOps pipeline when it has a separate security sign-off, governance, regulations and even corporate policies that give security the final word.
Get early security feedback
As tempting as it might be to disband or subvert the security team, that doesn't improve application quality nor does it help establish a DevSecOps pipeline. Security is there for a reason, to effectively stop bad applications or features from getting out the door.
IT must gather earlier feedback about how secure the software is. The developer's role should include efforts to ensure security standards are met.
Developers must test on some scale that returns early feedback, but still provides them enough time to code. Additionally, developers must perform this assessment without security professionals embedded full-time to advise them. Security specialists must still scan and evaluate software at the end of the DevSecOps pipeline. They don't have the skills or availability to dictate how others work during the development process.
A DevSecOps pipeline adds security tooling and checks in the form appropriate to each stage of code development, build, test and delivery.
Assess source code security and components
To start converting the DevOps pipeline to DevSecOps, add security-minded static analysis tools that look for SQL injection and race conditions. Use tools to run static analysis on source code right after the unit tests finish. SonarQube provides security-oriented rules and checks via plugins like Find Security Bugs to get even more early feedback on source code security.
Next, assess the security of the countless third-party components the frameworks rely on. Check for components with known vulnerabilities. The Open Web Application Security Project (OWASP) Dependency Check identifies libraries that require updates for security reasons.
Evaluate the running application
At this point in a DevSecOps pipeline, the team is ready to compile and deploy the application. Piggyback some security testing onto the automated functional tests. Implement web testing through a passive security proxy, like OWASP Zed Attack Proxy (ZAP) and look for cross-site scripting and cross-site request forgery vulnerabilities. ZAP watches while the automated functional tests run, so you only need to make time to read the results.
Once you implement passive security testing, then think like a hacker would. Run tests that actively attack an application. These tests take a while to complete, so they should probably come later in the development lifecycle, possibly in parallel with other tests. Tools like W3af, Wapiti and Sqlmap can help to run these checks.
Deploy to a production-like environment
When a deployment under test looks like a deployment you'd send to production, you can gather security posture information early in the process, as seen in QA or staging deployments. It might seem like a nuisance to deploy to a locked-down, hardened, production-like system rather than a wide-open development or test configuration, but the benefits of early feedback and testing opportunities outweigh the inconvenience.
Configuration management tools like Chef, Puppet, Ansible and Docker for containers deploy software and supporting resources the same way in all environments. You can scan the deployed system during development in the DevSecOps pipeline and avoid late surprises during security's final audits in preproduction or production.
Open Vulnerability Assessment Scanner checks the deployed systems for security problems in the OS, as configured. Nikto2 looks specifically at the web server configuration to see if there are any vulnerabilities or likely problems the user needs to address. Open Security Content Automation Protocol enforces security baselines, also known as security standards, from the National Institutes of Standards and Technology.
DevSecOps adherents can even do a security audit using a tool like Chef InSpec. With preconfigured security profiles, the tool gives feedback related to compliance guidelines -- long before the build goes to security for the official compliance check.
Build security karma
When you identify vulnerabilities and opportunities to improve, these process changes become part of the normal development, testing and deployment routine. Rather than wait until the end of your pipeline for security to point out potential problems, you can proactively improve security posture.
While the security team uses different tools for its audits and vetting, it essentially searches for the same types of vulnerabilities. When developers test along the way, it builds confidence on the security side that they won't uncover anything obvious that was missed earlier on.
Security professionals can step in to advise testers and developers on how to remediate problems that arise. Done properly, DevSecOps implementation frees up time for collaborative attacks on thorny issues.
Gradually, security should get more involved with the dev team to guide it on architecture and design decisions. Even if security pros never become day-to-day members of the team, the fact that an organization has added security standards to the role of a developer will change the whole dynamic of application releases. Instead of adversaries, developers will begin to see security as team members who try to enable the best possible product.
Continuously improve software
The process to improve security posture never stops. You must continually adapt and adjust security testing within a DevSecOps pipeline to respond to changing threats and security needs. Developers should learn to find and avoid certain types of established security issues, which enables the team to focus on the latest security priorities.
When you miss weak spots and get burned, learn from those mistakes. Add new tools that better address security needs and better serve compliance, governance, regulatory and process requirements.
As a result, hopefully, the final security scan before release becomes a formality. Or, even better, a thing of the past thanks to an SDLC with security baked in throughout. Embrace the continuous testing and feedback aspects of DevOps, and accept the evolution to DevSecOps.
