This is a guest post by Richard Gall and appeared originally on Security Boulevard.
It has never been more critical than it is today to get things right in terms of cloud safety and security when building new software. Yet many organizations are still suffering from massive breaches, vulnerabilities and supply chain attacks. According to a report released by Check Point Research, in 2021 the number of cyberattacks against corporate networks soared by 50%. That the year ended with the emergence of a particularly dangerous vulnerability inside Log4j—the popular open source logging library used by nearly every enterprise including Amazon, Apple, Microsoft and Twitter—only underlines the importance of moving security upstream and integrating it into the development process.
The research is clear: The earlier you can identify security issues, the less time, money and customer impact those issues will have in the long term. That’s true on two fronts—it benefits both your external customers and your internal engineering organization. The Systems Sciences Institute at IBM reports that the cost of a bug increases significantly based on how far down the software development life cycle it is found—especially in distributed, cloud-native environments. “The cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase,” IBM noted. Such findings emphasize that engineering decisions aren’t separate from a business’s bottom line; they are inextricably linked to it. Getting it wrong and overlooking things like security have the potential to be immensely damaging.
This realization has given rise to what’s sometimes referred to as shift left security or DevSecOps. While such terms can—like many in the software industry’s lexicon—inspire fierce debate about their exact meaning, the key point behind both is that software developers must play a larger role in the security posture of organizations.
Automated cloud security
Cloud-based systems are becoming the go-to system of choice for a lot of companies. This is because businesses no longer need to have a physical server room on-site where all important files and sensitive information can be stored. Instead, you can now host everything online; this makes managing and scaling infrastructure much easier.
That said, the rise of cloud also means that you need security solutions that are built for cloud-native applications.
By building tools that developers actually can use and want to use, issues will be identified earlier. This reduces the burden on everyone involved in the development lifecycle: Security teams have fewer alerts downstream to triage and developers have fewer out-of-band bug-fix tickets to address. Put simply, it provides a way to bring the worlds of software development and security closer together for more effective results, much like the way the industry saw the worlds of development and operations become more tightly intertwined with the advent of DevOps.
Cloud-native security solutions help ensure secure code at build time and also help secure the delivery pipelines that cloud-native applications rely on. The current focus on supply chain security is unsurprising in the context of the growing number of supply chain attacks; as the recent SolarWinds attack demonstrated, the scale and extent of their devastation cannot be overestimated. Unit 42’s Cloud Threat Report highlighted the roles that misconfigurations and vulnerabilities play in providing entry points for malicious supply chain attacks and the importance of being more proactive in defending against them.
Simplifying permissions
One of the hardest parts of the software development process is building permissions from scratch. When developing an application, you need to give your users an added level of control and security. The rise of cloud has only multiplied the complexity and surface area of this problem. Now, developers need to think about who is allowed to do what within each microservice, a task which is often simply not possible, as the number of services can sometimes run into hundreds or even thousands.
Luckily, as the world of authorization has matured, it is easier to check IDs “at the door” and the industry is now ready to tackle the more complex problem of permissions and what people are allowed to do once they are actually inside the application.
Security is shifting left towards developers
Some may say we are asking too much of cloud software developers. They’re not, after all, typically security experts, yet they are now being tasked with the reliability and security of the code they write. While it’s true that this sort of approach will place new demands on cloud developers, it’s important to acknowledge that whether we shift left or not, devs will inevitably have to interface with security one way or another.
For example, if buggy code is causing performance issues, the IT team will ultimately have to track down the developer to try and fix it. The same is true with security — if the code contains misconfigurations, vulnerabilities, and faulty permissions, the developer will hear about it, whether that’s through a help desk ticket or another meeting on their calendar.
In an ideal world, shifting security left should mean empowering developers. It’s not about giving them more problems to contend with, it’s really about getting out of their way and making it easier for them to work more closely and efficiently with security experts. Equipped with the right tools, that help desk ticket or meeting won’t be necessary; the issue will already be resolved. That means developers can focus on doing what they really want to do day-to-day: Ship better code faster than ever before.
