Go to your most used app on your phone. Now check the version history of that app. Chances are updates occur every week, if not more frequently. For example, the JP Morgan Chase banking app has had five updates in the past month alone.

This isn’t unusual. Industry-leading companies are deploying new software capabilities faster than ever before. In fact, Google found “elite” organizations had 973 times more frequent software deployments than low-performing organizations — a number that continues to grow exponentially yearly. 

Unfortunately, many organizations have to sacrifice consistent and comprehensive security to achieve faster deployment times. But what if there was a way to prioritize speedy software delivery and develop more robust security practices along the way?

The answer lies in DevSecOps — an approach to culture, automation and platform design that establishes security as a shared responsibility. Organizations can get the best of both worlds by adopting DevSecOps best practices and open source technologies without sacrificing security or go-to-market ability.

In-app security is becoming more crucial — and more complex 

As pressure mounts to shorten software development times, organizations must balance the need for speed with a growing volume of cyberattacks. This increase in attacks isn’t a new phenomenon — attacks have steadily risen over the past decade. But what has changed is how much the average consumer cares about attacks. 

As a result of the data privacy movement, customers and employees — especially digital natives — are prioritizing the security practices of the companies they associate with. For example, when it comes to social media, over half (52%) of global consumers would leave their current platforms for ones with stronger data protection measures. 

Security is quickly becoming a key point of differentiation, giving companies a competitive advantage. Yet too many products and offerings are built to be released quickly and not necessarily securely. It’s not deliberate — it’s a holdover from how security was historically managed on-premises. 

When on-premises, security was less complex. Because applications were hosted offline, organizations could simply place barriers, like firewalls, around the perimeter. It was easy (and practical) to address security as an afterthought, adding access control measures after the software was already built or a security incident occurred. 

But today, applications are largely hosted on the internet, meaning security is no longer as straightforward as it once was. The cloud, APIs, microservices and containerization involve many more discrete, in-app components — creating additional openings for bad actors. Organizations can no longer put a barrier up around the entire application. Instead, each vulnerability must be secured by access control measures. 

Because security has evolved, it’s no longer efficient or effective to address security after new features are built. Yet that’s still how most organizations approach software development and security. A retroactive approach overcomplicates security — causing inconsistently applied or forgotten security features — and slows down deployment times.

Instead, organizations must prioritize building apps securely by design and incorporate security as early as possible in the software development lifecycle. 

4 steps to balance speed with security 

Security and deployment time shouldn’t be at odds. In fact, good software development prioritizes both of these forces equally. DevSecOps can prompt your organization to think about, plan and incorporate security during each phase of the software development life cycle — ultimately helping you build secure software from the start.

By adopting several DevSecOps best practices, you can ensure your software is ironclad while still getting updates out the door as soon as possible: 

1. Have the right people in the room. When planning new features, it’s essential to listen to the voices of those who will actually design and develop the product. CTOs or CIOs often plan quarterly planning meetings that include upper management, not software architects and development leads. Your architects can contribute tremendously to brainstorming sessions by acting as checks and balances — identifying which ideas are realistic or need to be improved upon from a security perspective.

Beyond inviting the right people, you need to ensure they have the space to speak up. If architects only feel comfortable agreeing with the ideas already out there, your organization will fall into a pattern of self-confirmation bias.

2. Incorporate security as you build. Too often, we approach security in terms of incident response and try to correct vulnerabilities after a breach has already occurred — known as reactive security. While active threat detention measures and incident response plans are undoubtedly necessary safeguards, it’s more effective to focus on preventative security by keeping attacks from happening in the first place. 

Security should be considered in the architecture phase when software teams are designing and planning new features. While planning security may take a little more time upfront, it will allow you to build features with security already baked in, preventing more time-consuming activities down the road — like shoehorning the proper measures or entirely rebuilding systems after the fact.

3. Establish ownership. There’s a misalignment between IT leadership and on the ground employees about who owns security responsibilities. For example, when defining policies that control how cloud applications are secured and managed, only 21% of developers believe the IT infrastructure and operations team are responsible, yet nearly 45% of IT leaders believe it’s IT infrastructure and operations. 

Even though DevSecOps establishes security as a shared responsibility, it’s essential to explicitly designate roles to keep items from falling through the cracks (and to prevent finger-pointing). This ensures each team member — from senior architect to junior developer — knows security is a high priority and will allocate their time and effort accordingly.

4. Use an open source base. DevOps is all about the agile development and delivery of software, and DevSecOps is founded on a similar principle. Building, implementing and testing security features can be time-consuming when done manually, which is why it’s crucial to take advantage of open source technologies. 

 Open source tools are founded on the collective knowledge of thousands of experts worldwide — making them more comprehensive than proprietary security solutions. These tools lend themselves to automation, helping ensure security is both quick to implement and standardized. But don’t just take my word for it. Large organizations like Mercedes-Benz and Netflix have leveraged open-source technologies for years. 

Moving from reactive to proactive security

Microsoft CEO Satya Nadella often says, “Every business will be a software business.” And that couldn’t be more true. No matter the goods or services a company provides, software is the ultimate vehicle for the customer experience (consider how the digital experience provided by Uber completely changed the taxi industry). As a result, many organizations are feeling pressure to deliver new features faster than ever before to stay competitive.

But without the proper security, even the best-made application with the highest quality user experience will lose out to a more secure competitor. To earn and keep consumer trust, while also creating software as quickly as possible, you must start building applications to be secure by design. And a DevSecOps approach paired with an open source base can help your software teams do just that. 

If you only take away one thing, remember this: You don’t need to sacrifice security for speed. Both are possible with DevSecOps.