Is Balancing Dev-Owned Security and Velocity Possible?

About

This content is brought to you by Jit - a platform that simplifies continuous security for developers, enabling dev teams to adopt a ‘minimal viable security’ mindset, and build secure cloud apps by design from day 0, progressing iteratively in a just-in-time manner.

‍

Originally posted in Thenewstack

‍

Many cloud hosting providers may promise fast delivery of great products, plus built-in security, but is it possible?

With digital transformation efforts in full swing across industries, it’s easy to see how targeted or innovative startup-based software products create a competitive edge.

But it’s not just the product itself. The velocity at which companies can ship valuable products has a direct impact on their business results, today more than ever.

Development velocity is the speed at which a company can deliver great software.

Assuming all other coding essentials are equal — for instance, code impact and quality — higher velocity is a main goal in software delivery. It is built on the basic

premise of delivering impactful products to customers faster and generating high business value.

‘Ship it, ship it, ship it. Push on strict estimates. Give us something to cling to’ 



‍

Jokes aside, a research from McKinsey & Company shows that the top 25% of high-velocity companies enjoy 4-5 times higher revenue growth and 55% higher innovation.

‍



Source: Mckinsey & Company based on data from Capital IQ; Developer Velocity Survey

How Do Cloud Native Organizations Chase High Velocity?

McKinsey’s survey determines that Developer Velocity involves no less than 46 drivers across 13 different dimensions. Only a handful of those drivers are directly related to a developer’s talent and development within an organization. A majority of these drivers are instead to do with Agile, DevOps, CI/CD, Everything as Code, and leveraging Open Source Software (OSS) wherever possible — best practices for modern development houses rather than individual developers.

A good reference is the book “Accelerate,” by Nicole Forsgren,  Jez Humble, and Gene Kim, which demonstrates how good engineering practices — quantified in the well-established and researched DORA Metrics — have a direct impact on software quality and velocity.

DevOps is essentially the enabler for shortening delivery lead time and mean time to restore, by increasing deployment frequency, and decreasing your change fail rates. They are all the byproducts of better automated processes with everything from infrastructure to post-deployment delivered as code — and security is ready for such a transformation as well.

There’s a Gap…



‍

Today, application security is evolving to meet the speed demands of DevOps and the growing complexity of modern software programs. DevOps principles and practices are being applied to security architecture and processes with many emerging tools looking to solve different aspects of the AppSec challenge. The DevSecOps design pattern is an example of shifting security left and baking it into the repeatable DevOps pipeline. However, that said, “Application Security” mostly only refers to “code security” and thus only addresses part of the “tech stack” and part of the problem.

But, usually, that is hardly enough and the shift-left approach isn’t solving product security. In fact, in many cases, “shift left” shifts a lot of bad stuff to developers.

A couple of reasons for this, First, there are a lot more attack surfaces today, as you have all seen across the entire software supply chain — from your own code through all the integrated packages and third parties that your applications require to properly run in production. Modern application development is pushing “Everything as Code.”

This approach requires security testing at multiple levels on the infrastructure, application software, and data layers to protect from a variety of possible attacks. We are no longer looking just at the application security itself, but the configuration of other infrastructure and services that may pose a target through code. This can have substantial downstream implications if compromised. To add to this, it comes with a constantly changing threat landscape, with new findings, CVEs and exploits being discovered daily.

Shifting everything left means that there is no room “left” anymore. Development cycles are so short and there is so much to deal with, that with today’s shift-left tools you can barely scratch the surface, and achieving continuous and minimum viable product security is not feasible for most teams who are not resource-rich. Did anyone say startups?

In order for high-velocity development to not come at the cost of security, security can not be partly managed by developers, but rather, it needs to be owned by them.  This starts with the first line of code — it must be “born-left” and not merely “shifted” left. Yet with developers already tasked with testing, deployment and operations, how can they also deal with security and maintain velocity? “Democratizing” this capability has to start with a fundamental change in perspective on product security.

How Can You Do Both Dev-Owned Security and Maintain Velocity?

Embarking on this journey requires a dev-native but also a dev-friendly approach, with the following specific components to help increase the likelihood of success, uptake, and repeatable processes.

Minimum Viable Security — Automated Please

Take a look at Minimum Viable Security. MVS encompasses:

• A customized, and continuously updated, Minimum Viable Security Plan that covers the threat landscape and the baseline security needed for product protection. Instead of a document or a spreadsheet, this plan needs to be “in-code”, and managed like every other piece of code, in your code repository.
• Security-as-code automated orchestration embedded in the CI/CD pipeline, with noise reduction features.
• And actionable results — only the relevant and important ones (not a laundry list of thousands of threats that overwhelm the developer), along with in-context, in native to dev environment mitigation.

Open Source Security Tools

As a rule, it’s good to stick to open source security tools when possible to help construct your processes. Not only are they often better maintained, but can be customized to your own requirements. Look for options that integrate well with your current DevOps tools and stack. Still, consider that open source integrations are not effort-free — you may want to search for automation here as well. (As the age-old adage goes…”Linux is free if your time is worthless.”)

A Dev-Native Security Environment

Reducing cognitive load, context switching, and knowledge gaps requires a move towards making baked-in security dev-native. And how do we do that? By embedding the tooling, configuration, testing, notifications, and chance to address security concerns right within the dev environment itself. If we are going to call ourselves born-left, then it needs to be so native to the dev environment, it’s seamless. Most developers are not security experts and they need to focus on coding — so we need to make security tasking as dev-friendly and as frictionless as possible.



Who in the Dev Team Is the Security Champion?

All this is much easier to implement when someone on the team is a developer but is also highly knowledgeable in security (or that you are lucky enough to have DevOps or DevSecOps as part of your engineering organization). You will need a well-versed advocate to build and iterate over a born-left security process.

The Verdict?

Can secure applications be delivered quickly? Yes, they can.

Of course, we must automate as much as possible, and create different security policies for different types of projects to achieve true Minimum Viable Security, because as Redmonk says, “DevEx is Security”. But the real challenge in balancing developer-owned security and speed of product delivery is in overhauling security processes so they follow a similar design pattern and tooling to what is now standard in CI/CD. Armed with this knowledge and your security champion, you’re ready to start baking in security from the ground floor.

‍