There is nothing wrong with understanding this post’s title as a play on the old adage: “An ounce of prevention is worth a pound of cure.” Indeed, best security practice dictates that avoiding trouble is faster, cheaper and easier than fixing trouble after it manifests. From this basic and humble insight, companies and organizations should understand that working from ongoing threat intake and analysis, and responding where potential, trending threats or risks present themselves, is the best way to improve and enhance their security posture. This applies most directly to code bases built and maintained in-house, and also to applications and services that use open source components and libraries, where remediation advice may also be available.
Readers familiar with the integration of security into development and operations — that is DevSecOps — understand that folding security into development and maintenance lifecycles involves more than executive decrees. Developers will need to interact with security team members on a number of fronts to become more security-savvy and proactive in writing and maintaining code.
For one thing, developers must learn how to understand threat intelligence from the point of intake. They must also learn how to use appropriate filtering and prioritization on such intelligence, to separate relevant, actionable intelligence items and then to rank them for handling based on associated risks and exposures they present. This usually requires input and coaching from security professionals, to familiarize themselves with intelligence feeds, and using appropriate tools and platforms to provide filtering and priority, impact and risk data to drive a constant, continuous process for threat intelligence intake and handling.
For another thing, developers must also learn how to understand and act upon remediation advice — which often stops short of instruction-level guidance on code changes — to fix, avoid or work around potential security vulnerabilities and exposures that threat intelligence provides to them. Here again, coaching (or even training) from security professionals on secure coding practices and testing techniques may help developers adopt the right mindset, and use the right tools to up their security smarts when writing, testing, fixing, and maintaining the code bases they work with. Many organizations find it helpful to embed a security team member or a contractor with both security and development skills to act as a mentor, resource, and guide as the DevSecOps vision unfolds and becomes the norm for ongoing development workflows and practices.
Whenever organizations change how they handle and structure workflow, all team members and management levels must be informed and educated on what’s driving those changes. Ideally, team members in development, operations and security will not only relate to the savings and increased utility that improved security brings to the bottom line, they will buy into the idea that good security is an essential element across the entire software development lifecycle (SDLC). At the same time, it is helpful for the various teams to understand their work from other teams’ perspectives, so that developers understand the concerns and priorities of the security and operations teams, operations people understand the concerns and priorities of development and security teams, and so forth.
Finally, culture change requires buy-in from management, executives and key stakeholders. Mere lip service will not bring the kinds of fundamental shifts in working habits, outlooks and priorities that genuine buy-in from the top down makes possible. In this case, “walking the walk” turns out to be far more important (and meaningful) than “talking the talk” to promote DevSecOps thinking and action.
With the right support, training and across-the-board buy-in, making DevSecOps happen is almost automatic. This will take planning, time, effort and some expense, but once in place, developers quickly learn to integrate threat intelligence and remediation into their everyday code creation, testing, and maintenance practices. The best outcomes occur when their code analysis and testing tools incorporate security and remediation info automatically, so their IDEs bring security-related findings and fixes right into their everyday toolsets and interfaces. Hopefully, this will smooth out some of the learning curve involved in adopting DevSecOps. It will most certainly make it easier and automatic for development and test professionals to incorporate, understand, and act upon security-related actions and information as a routine part of the development process.
The continuous integration and continuous deployment (CI/CD) model that is part and parcel of DevOps philosophy, tools and workflows adapts most easily to bring security into the mix through automation and integration as well. These development practices promote development and delivery of software to production quickly, safely and reliably. Bringing the security dimension into play means that check-ins into code repositories, which trigger automated builds and testing regimes, also incorporate security intelligence, related remediation, and security scanning tools and processes as part and parcel of the normal development process.
All the set-up — namely, teaching developers about secure coding practices, how to use threat intelligence and remediation advise, and how to properly test code for security as well as functionality, integrity, performance, extensibility, and so forth — is simply to enable developers to handle security inputs and concerns as part of the overall development process and experience. Properly implemented, DevSecOps does not change what developers do, or how they do it. What it does change is how they think about the design, development, testing and maintenance aspects of coding, to make sure that security is an important and valuable element at every step of the SDLC. Thus scanning code to ensure proper security, and address potential or emerging threats and vulnerabilities, gets baked into the organization’s thinking and behavior.
