7 Recommendations to reducing risk before production

When focusing on reducing risk before an application enters production, it’s important for tech leaders to remember that we are long past the days when security tools couldn’t be integrated with cutting-edge developer platforms. Organizations can easily reference multiple publicly identified breaches that will compel them to take stock of their own houses and begin doubling down on security investments.

We’ve seen that the rapid pace of the DevOps movement brought great rewards to many companies, along with great risk. And so, DevSecOps becomes a buzzword and everyone wants “in.” Except you can’t buy DevSecOps: You must break it down into the tools, processes, and people/education/awareness that needs to be spread throughout the development lifecycle. Everyone can (and should) own a piece of it.

We offer the following 7 recommendations to reducing risk before an application enters production

• Security is a shared responsibility: security is a responsibility to be shared across multiple stakeholders—security teams, software engineers, and managers all have a role to play.

• Invest in tools that matter: Invest in tooling and automation to free up valuable developer resources and, at the same time, reduce risk.

• Follow zero trust and design patterns: Don’t assume anything about the target environment; it might be misconfigured or configured for a differing purpose. Follow zero trust and design patterns to ensure your application security doesn’t rely on assumed configurations, and where external security dependencies are required, verify those configurations with security and operations team members.

• Prioritize risk-related responses to save time and money: Prioritizing risk-related responses over new features in development, and leveraging automation to ease the burden wherever possible are key to saving time and money. By leveraging tools to shift-left the security analysis of software composition, developers can fix security-related issues before they are encountered later in the deployment process (potentially causing bottlenecks). The least costly issue is identified and remediated during development, and the most costly issue is identified after deployment (and then remediated in new development activity).

• Enable a learning culture at your organization: Ensure that security tools are shared between developers and security engineers, closing the gap and providing shared context and knowledge.

• Scalability>bespoke: Leverage scalable tools that can capture a view of all environments whenever possible, rather than using bespoke tools.

• Set new tools to audit mode first: If you’re just starting out with a new tool, configure it to operate in audit mode rather than enforcement mode, but plan to move to enforcement mode in the near future. This way, development activities can still flow while you gain visibility of risk.

We can meet the security needs of the organization AND maintain the pace of delivery that DevOps has given us, but this requires a security conversation before we write a single line of code. It requires policies, tools, and automation to be involved as far left as possible and to provide feedback as quickly as possible. It also requires us to assume that a bad actor is already inside the network. The market is more than ready to help with mature solutions, guidance, and deeply invested security research centers, but needs organizations to start by clearly understanding the security problem they are looking to solve: not just adopting “DevSecOps” as a term but taking a clear, action-oriented approach to de-risking the application development and deployment process.