App development now happens at breakneck speeds as companies recognize the need for first-to-market applications that exceed consumer expectations for usability and performance. The root of this rapid release cycle? DevOps—the combination of development and operations teams to deliver best-in-class applications ASAP.
However, more apps on the market quickly mean more chances for security issues. As noted by Bank Info Security, 60 percent of all breaches over the last two years started with known software vulnerabilities. Bottom line? DevOps is getting apps out of development, but lack of security puts them in harm’s way. There are no second chances for first impressions; users won’t return if applications expose personal data or become malware distribution drones.
The solution? DevSecOps: Security as a fundamental aspect of application development. Here’s what you need to know.
DevOps’ biggest advantage? Speed. Its biggest drawback? Security. Consider: Recent data shows that the number of Android apps released worldwide daily is just over 6000. The result? It’s the end of the post-security era: App security can’t occur after development because there’s no lull, no opportunity for IT teams to thoroughly assess the risk of new code and make necessary changes—organizations in a mobile-first world need to push one app out the door and make room for the next.
DevSecOps emerged as a response to this shift. Given the incredibly short window, new apps must make a good impression on users and stakeholders alike; security by design is now imperative in app evolution. Put simply, you don’t get a second chance at a first impression.
While DevOps has been part of IT culture for over a decade, DevSecOps is relatively new. Still, it’s gaining ground—96 percent of organizations surveyed say producing secure code is “desirable” or “highly desirable.”
Put simply, DevSecOps is the combination of development, security, and operations in the app development lifecycle. Instead of security being “tacked on” just before applications go live, DevSecOps puts it front and center with development and operations. Ideally, adding security to the initial stages of application design helps identify and eliminate code flaws or vulnerabilities that malicious actors might otherwise discover before being fixed. While this means more time investment at the beginning of the development cycle, it reduces the risk of zero-day or open-source vulnerabilities that could force the creation of immediate hotfixes or the removal and redesign of applications from the ground up.
Most organizations want to adopt a DevSecOps model, but only eight percent have developed best practices that enable this digital transformation. What’s the disconnect? It starts with culture. Developers and security teams may not agree on certain aspects of app development, and continually evolving stakeholder expectations can make it difficult to implement DevSecOps effectively.
Start by understanding that there’s no “finish line” here—all apps could be more secure, and no app is ever perfect. DevSecOps reduces the total number of vulnerabilities and the time spent identifying and eliminating these vulnerabilities after applications go live. Next, ensure that communication is front-and-center: If devs, infosec, and operations pros can’t speak freely about the projects they’re working on and what they need to be successful, DevSecOps will stall out in the first few months.
Also critical? Security processes adapted to existing developer processes wherever possible. While developers also need to compromise, infosec leaning into the Dev side of the equation can help reduce friction and improve time-to-market. Last but not least, implement strong monitoring controls. Just like any new initiative, metrics are key to success: You need to know where processes are working, where they need improvement, and where they’ve gone wrong.
You’ve shifted focus and created a DevSecOps team. You’re prepared for the culture shift. So, what does DevSecOps look like in practice?
From a basic security perspective, it’s continuous testing for zero-day, open-source, and known code vulnerabilities (both statically and dynamically) with each iteration of your application. Instead of attempting to round up and mitigate multiple security issues just before deployment, adopting DevSecOps allows iterate security with app function and performance evolution.
If your application eventually runs in a low-trust or untrusted environment, such as on a mobile device, application shielding can be incorporated into your DevSecOps process to harden apps against unwanted inspection, tampering, or reverse-engineering. If your application has unique intellectual property (IP) or accesses sensitive information, you may be at risk of being targeted by hackers—regardless of your basic security profile. By incorporating app shielding into your DevSecOps pipeline, it’s possible to harden and protect high-value applications that run in untrusted environments.
Security is a late addition to DevSecOps, but don’t let its position in the term fool you—security-by-design is the first priority of any DevSecOps deployment. By linking creative, functional, and defensive aspects of your app development to create a continuously iterating and reinforcing process, it’s possible to embrace the speed of app deployment without sacrificing security.