Can Application Security Be Pain Free?
Application security is hard, and it’s even harder to do right. If it were easy and straightforward, executives wouldn’t be held accountable for breaches with jail time! In today’s digital‑first world, securing modern applications against cybersecurity threats has become one of the most pressing challenges for enterprises to overcome.
Organizations are continuing their efforts to keep attackers at bay – cybersecurity spending is expected to reach $123 billion in 2020, and cloud security is projected to grow by 33% despite the economic downturn caused by the global pandemic.
But the odds are tough:
- More than 20% of data breaches discovered during the last year occurred due to code errors, and over 40% of those attacks targeted web applications.
- Hackers launch an attack every 39 seconds, an average of 2,244 times per day.
- On average, only 5% of the apps in a company’s portfolio are properly protected.
- The average cost of a data breach in 2020 was $3.86 million per company.
- 39% of British businesses have already fired employees for security breaches during the pandemic.
With new breaches hitting the headlines every day, business leaders not only want – but need – to better prioritize security in their processes.
So, if everyone is already doing application security, why are so few doing it well?
Digital Disruption Brings New Security Challenges
Over the last decade, application development has undergone a massive transformation in response to ever more demanding business expectations. More than half of organizations now claim that without applications, they cannot operate. Another 67% believe that digital transformation efforts, such as IT and business process optimization, improves release velocity of new products and services.
As a result, development teams are using advanced technologies like cloud computing and microservices, in conjunction with DevOps principles, to innovate faster and stay competitive in an increasingly crowded market.
But like most things, this progress has come at a cost. The fast pace of DevOps has left security teams scrambling to keep pace and still install appropriate security guardrails. Traditional security practices used to occur in the final stages before release, but this no longer works well with the rapid release cycles of agile software development. For instance, Amazon reached 50 million production deployments per year even as far back as 2015 – that comes out to about one release every second.
It’s no surprise that the speed of development is fast outpacing the rate at which security teams can check configurations and scan for vulnerability, especially considering that developers now outnumber security professionals 500 to 1.
Additionally, modern application environments represent a nearly infinite attack surface. 87% of enterprises are now multi‑cloud, and most are struggling to provide consistent security across multiple application architectures and infrastructure. There is no margin for error – organizations must stop attacks every time or risk a breach, public embarrassment, or billions of dollars in damages. Malicious actors only need to be successful once to win.
The pressure to keep up, and do so securely, has led to a gradual reframing of DevOps as DevSecOps, where security is “shifted left” and introduced earlier in the software development life cycle, where capacity is more flexible and open to change. In other words, security is baked into the processes and tools so that issues can be found just like any other defect and addressed more efficiently.
Organizations Are Struggling to Achieve Secure DevOps
Ask someone to describe DevSecOps, and you might get one of the following answers:
- “Bringing security to DevOps”
- “Security as code”
- “Everyone is responsible for IT security”
But understanding the need to incorporate security practices earlier in development is very different from implementing it – and DevSecOps has proved to be far more nuanced in reality. While most businesses understand the intent of DevSecOps, they are still unsure of how to go about actually doing it. In fact, just 14% fully integrate security throughout the software development lifecycle.
Recent research also shows that while 65% of security teams report shifting left, less than a fifth are doing the scans necessary to verify that claim. The same report suggests that most security teams don’t have processes in place to monitor and protect cutting‑edge application technologies, such as microservices, APIs, and cloud‑native/serverless.
This lack of visibility leaves security organizations running blind when problems surface in production – and the later in the development cycle vulnerabilities are discovered, the more costly it is to fix them. A study by IBM System Science Institute suggests that compared to a defect identified during early design phases, fixing a defect found during implementation can cost 6x as much, and a defect uncovered in production 100x.
Even more disturbing, nearly half of enterprises admit to consciously deploying vulnerable applications to meet tight deadlines.
Everyone may want secure applications, but it’s clear that compliance and security oversight are often overlooked, even deliberately avoided, in favor of achieving faster and more frequent deployments.
The Great DevOps-SecOps Divide
One of the most significant issues lies with older, ingrained perceptions.
In the siloed, waterfall world of the past, teams worked independently from one another with rigidly scheduled handoffs required between distinct phases. Security operations (SecOps) teams often introduced security functions only during the final stages of the development and release process, resulting in delays. And while cross‑team collaboration has had to improve over time to accommodate more agile development practices, the fact remains that development and security teams strive towards different core goals, often causing organizational misalignment – and inevitably, friction.
If DevOps teams are the engine driving innovation, SecOps is often viewed as the brakes that stop forward motion. 48% of technical professionals believe security is a major constraint on the ability to deliver software quickly.
On the other hand, SecOps and application security teams are focused on thorough testing to identify vulnerabilities, potential risks, and possible compliance issues. They feel developers are running rampant, especially with the specter of shadow IT in the application stack looming large – and they struggle to hold developers back as they charge ahead at full speed.
Successfully putting the “Sec” into DevSecOps hinges on changing these older cultural biases, reinforcing the need to embrace security, and empowering teams with the right tooling and automation to make smarter decisions without slowing down the entire organization. In essence, DevOps and security teams are all aiming for the same goal – a high‑quality, timely product. The difference lies in how they are used to measuring and defining what that means.
The truth of the matter is that development won’t be slowing down any time soon. 38% of developers now release monthly or faster, and 54% of containers live for 5 minutes or less. Continuing to view security as a separate entity bolted onto the code, instead of a key feature that must be embedded end to end, only slows processes down and reduces efficiency.
More than ever before, now is the time to transform how security is applied to DevOps.
Bridging the Gap to Deliver Speed and Security
The core questions for app security then become: What makes it easier for DevOps teams and application security teams to collaborate? What does built‑in security really look like?
For organizations that want to improve their DevOps security, here are some key points to focus on:
Automate security as much as possible.
Invest in security solutions that can be embedded directly into the CI/CD pipeline using automation. This makes it easier to secure apps without having to sacrifice as much development speed for the sake of security. Adopting technologies like static code analysis, dynamic analysis, and pen testing reduces risks, and alerts developers to potential problems. There will never be enough security professionals to handle all security issues on their own, so use automation whenever possible.
Build security as a guardrail, not a gate.
Provide appropriate guidance and tooling so that security becomes a guardrail rather than a gate. For example, ensuring that DevOps teams have access to templated policies enables them to align their applications with security requirements right from the start, without adding unnecessary time to development. Applications and security policies can also be tested as part of the CI/CD pipeline, so they are checked like any other functional specification. In short, it’s important to provide developers with everything they need to create and test applications with the appropriate security controls applied, or they won’t do it. Empowering development with a better understanding of security and self‑service compliance reduces vulnerabilities and risk to the organization. Developers always want to drive faster, so make it possible for them to speed safely.
Abstract security to enable more proactive responsibility.
The average developer cannot be expected to have the level of expertise necessary to stay current with all the latest security landscape trends – they have enough trouble keeping their programming skills up to date. Reduce complexity and make it easier to gain developer buy‑in by selecting solutions that provide simplified, easy-to-understand insights within the CI/CD feedback loop.
Make security adaptable, scalable, and reliable.
Secure applications with solutions that offer consistent, centralized, and self‑service security for any environment, including modern and distributed environments. For instance, AI‑driven security policy engines are one way to enable the adaptability necessary to support rapid change in applications resulting from CI/CD methodologies. Being able to adapt security policies in response to the latest attacks and identify dependencies makes it easier to assess risk and take action faster.
Modern Application Security Must Set DevOps Free
Gone are the days when security could simply be bolted on at the end of a process – in today’s world, integrated security must become a normal part of any DevOps implementation. Making security frictionless and adaptable enables development teams to power ahead without fear. Instead of a painful extra step that must be dealt with, modern application security can be a robust support system that empowers organizations to reach their business goals and guides them to even higher heights.
If you’d like to learn more about how the application security landscape is changing and what you can do about, download our free O’Reilly ebook, Web Application Security.
The post Can Application Security Be Pain Free? appeared first on NGINX.
Leave a Reply