Skip to main content
Application Security Image
Last Updated Apr 29, 2021 —

Why Better Security Means Better Products

Read this article and commit to DevSecOps, to expand what scenarios can be possible when all teams collaborate together.

Application Security

Over the past 15 years, businesses have learned a lot about the value of providing security. In that time, several high-profile data breaches have severely harmed companies' reputations — and bottom lines. 

What organizations may not realize is that there is a profound, positive transformation triggered when they integrate security into DevOps. The benefits go beyond avoiding the financial consequences of poor security. In effect, integrating security into the design and build phases of the process improves value creation at all stages of development, resulting in a better product all-around.

Simply put: teams that aren't constantly tasked to manage security vulnerabilities detected in production will have more resources to deliver better products. Security integration, therefore, saves time and energy while preserving teams' motivation to deliver the best value with each release.

When security is baked in, new innovations and product backlog priorities will be governed by security principles. Customers win by receiving products that are more secure and that have a higher level of quality, thanks to better-designed products with more resources dedicated to their integrity.

Shift-left security and governance to reduce the risk of breach damages

Non-compliance with regulations like HIPAA and GDRP can inflict millions in fines and other penalties alone. But there is also the risk of financial fallout from damage inflicted by the breach itself. In an extreme example, the NotPetya worm ransomware caused over a billion in economic damages in 2017.

Deeper, long-term effects can be felt when customers and clients consider taking their business elsewhere. According to a survey on breaches by CISCO, 29% of consumers say they actively research privacy practices and will abandon companies that exhibit poor data security and governance practices.

Seeking to avoid these losses, organizations have begun to "shift left" and embrace DevSecOps. The need to embed security within existing DevOps practices is a direct response to security threats, compliance and governance demands, consumer demands, and internal demands for greater efficiency.

"As 2021 progresses, more application teams will take full responsibility for their own security, with appropriate support from the security team," predicts TechBeacon. The report further speculates that teams will, "fully leverage automation to maximize velocity, and develop a culture of continuous improvement that allows each team to tune and optimize its processes."

This shift left approach has the effect of making security and governance priorities better integratedbetter-integrated into the development process while adding agility to needed security changes.

InfoSec experts aren't gatekeepers — they're enablers

A common consequence of the "security check comes last" approach to DevOps is that teams get caught in a reactive feedback cycle. Development releases a new build or new changes, and these changes undergo a security review before integration and deployment. 

By the CI/CD point, the development team has already moved onto a new sprint. If the security review reveals an issue, that means a change order is sent back to the development team. The needed changes may become part of the product backlog — or, worse, they may necessitate an emergency change, resulting in delays for other releases in the pipeline. Development work is interrupted, or entire teams get dedicated to putting out fires.

In the words of DevOps Digest: "Considering security separately from other DevOps processes can also lead to delays in the delivery of product features, because vulnerabilities must be assessed separately. These delays run counter to the goals and promises of most DevOps groups and organizations."

Security, compliance, and governance (SCaG) concerns demand immediate attention because they are seen as non-optional. Issues popping up at the end of the development cycle may be seen as an unavoidable inconvenience, but that is only because a process that performs SCaG assurance as a single step pre-release is inefficient. Obviously, it would be even more damaging to skip this step and discover issues post-release!

If SCaG isn't optional, then that means that only features, practices, and architecture that is secure can be released. In other words, without InfoSec's help, nothing could get released safely! DevOps organizations must, therefore, recognize the value in considering security at all stages of development. 

Shifting left to integrate security priorities has a transformative effect on teams, allowing them to focus only on work that has a high chance of clearing mandatory SCaG standards. In most instances, teams that integrate security and development exhibit measurable gains to productivity. According to Google's report "DevOps tech: Shifting left on security", "high-performing teams spend 50 percent less time remediating security issues than low-performing teams."

Incorporating SCaG into the native product cycle, results in teams spending less time on unplanned work while furthering innovation on product integrity. The goal is to recognize the intrinsic value of SCaG and make sure it is baked into all work performed, resulting in improved value delivery velocity and volume.

What does it mean to bake security into development?

"Best" practices will be individualized to the organization, but there are some general guidelines worth considering.

Shift security all the way left, to planning

  • Proactive security initiatives should drive choices made at the planning stages
  • New innovations should be considered based on SCaG merits, infosec team input
  • SCaG priorities should drive product backlog strategy
  • SCaG innovations should be seen as valuable as other new features

Automate security review before code check in

  • Testing an entire build is time consuming, but minor code changes or additions can be checked frequently to reduce the burden
  • Threat modelling algorithms can detect common issues specific to the product or organization, flagging code during automated review
  • Security Today suggests that, "security teams need to learn how to write code and work with APIs, while developers need to learn how to automate security tasks." This enables a culture change within teams, making it more likely that issues stemming from individual coding, database, or configuration item (CI) practices can be automatically spotted thanks to intuition.

Emphasize security in foundational architecture and development tools

  • IBM recommends using the principles of Traceability, Auditability, and Visibility when building tools, product architecture, and processes
    • Traceability Example: track CI across the dev cycle to determine where requirements are implemented into code, allowing for a more transparent control framework
    • Auditability Example: "Technical, procedural, and administrative security controls need to be auditable, well-documented, and adhered to by all team members."
    • Visibility Example: Monitoring and alerts, not just in operations but during the build.

Guide practices towards making SCaG compliance easier

  • In an extreme example, Google suggests: "Have the InfoSec team build preapproved, easy-to-consume libraries, packages, toolchains, and processes for developers and IT operations to use in their work."
  • DevOps Digest recommends employing the principle of least privilege (PoLP): When giving privileges to an automated system or account, provide the lowest level of access needed to complete the work
  • Use digital signatures to control commitment of code changes to the master branch, ensure code is only added or modified by a trusted source
  • For monitoring, log threat entry points and escalation process, set rules for abnormal behavior (whitelist good behaviors)

Let DevSecOps enable you to deliver better products, more efficiently

Incorporating SCaG into DevOps effectively makes these all-important initiatives a part of the agile cycle and agile feedback loops. Put simply, end-stage SCaG review is a waterfall holdover.

Being agile means more innovation, more integration of InfoSec expertise into products, and stronger processes built using iterative feedback loops. No longer enough to simply consider the cost of non-compliance — which can be on a bigger scope than many realize! Per DevOps.com: "when an organization is impacted by cybercrime, along with the costs of data damage, IP theft and business disruptions, it incurs legal and PR fees, drops in share price and the potential loss of customers and competitive advantage."

Instead, businesses must also embrace proactive SCaG practices, which allows development teams to spend less effort addressing threats or vulnerabilities after-the-fact. These resources can instead be committed to innovation, product improvement. Baking InfoSec into the product culture overall reduces the chances and impact of breaches.

Commit to DevSecOps, not just to avoid certain scenarios but to expand what scenarios can be possible when all teams collaborate together.

Learn more about adding agility to product pipelines while prioritizing what matters most in our webinar featuring Gene Kim: "The Key to Amazing Business Outcomes is Data"

More from the Blog

View more
Aug 01, 2018

What You Need to Know About DevSecOps

DevOps
Traditional security processes are often perceived as roadblocks to pr ...
Read More
Sep 11, 2019

Integrate Compliance and Security Testing into Continuous Delivery

DevOps
As any bread baker knows, there are four fundamental ingredients t ...
Read More
Shift Gears with Shift Left
Oct 07, 2018

Shift Gears with Shift Left

Continuous Testing
What is shift left? Shift Left is one of the biggest buzzwords in d ...
Read More
Sep 28, 2016

Fixing Flaws: Bridging InfoSec and DevOps

Enterprise Agile Planning
As software makes its way into every industry—from FinServ to FedTech— ...
Read More
Contact Us