Secure Cloud Native Projects Require a Clean Code Approach
Here’s how to tackle vulnerabilities with clean-as-you-code strategies.
Applications are an integral part of everyone’s daily lives. Working in the tech industry, especially in software development, can be exciting and rewarding. Software is literally changing the world and how people communicate, work, play and interact. The code that developers write has a profound impact on billions of people. It’s powerful, heady stuff – with that power comes great responsibility and Clint Cameron, product marketing manager at SonarSource, shares why and how enterprises need to tackle vulnerabilities better.
The sobering reality is that more and more vulnerabilities are making their way into production software, and the damage they wreak just keeps increasing. The bad actors out there just don’t stop looking for new and better ways to exploit. With increased complexity in modern software development, preventing vulnerabilities from making it into production becomes even more challenging. Reversing this trend means the software industry and software developers need to collectively take ownership for ensuring the digital safety of their users. Frankly, it’s irresponsible to profit off the users without a means to effectively protect them.
The advent of technologies such as cloud-native and Infrastructure as Code (IaC) enables shorter development cycles. However, it also means a dramatic rise in the number of lines of code and there are only so many eyeballs to go around on code reviews.
There’s no way to plug all the security holes 100% of the time. However, there are ways to minimize the risk to users. One of those ways is by adopting a Clean Code approach. Clean Code processes and tools that readily integrate with an existing development workflow make a major impact on mitigating vulnerabilities. These tools help you find vulnerabilities in your code while also reducing technical debt. Lower technical debt means code that’s easier to read and understand which, in turn, makes it easier to spot those pesky vulnerabilities.
See More: Scaling Cloud Security with Policy as Code
How Did We Get Here?
A primary reason that so many vulnerabilities make it into production is that traditionally, developers haven’t been tasked with keeping vulnerabilities out of the code they write.
It’s a bit like the automotive industry a few decades ago. Automakers were concerned with performance and aesthetics, while passenger safety took a backseat. Unfortunately, it took a lot of pain and suffering in the form of injuries and deaths for the industry to take the necessary steps to drastically improve safety. Now, driver and passenger safety is a primary concern for all manufacturers. This was helped by pioneering manufacturers taking ownership of the problem and driving the industry forward.
It’s the same for the software industry now. The industry is at a crossroads. Companies that will remain relevant and position themselves for sustained success will embrace software security and put that ownership directly in the hands of their developers.
Another important factor is that developers haven’t had control over the process. It may sound like I’m casting developers in a negative light. Actually, it’s the opposite. I think most developers, in their heart of hearts, don’t want to put users at risk. However, without organizational backing and sufficient tools, developers are not in a position to effectively eliminate vulnerabilities from the code they create.
What Dangers Are Lurking in Your Cloud?
A concept called the Shared Responsibility Model comes into play here. Security is a shared responsibility between the cloud provider, such as Amazon Web Services (AWS), and the customer. In this “shared responsibility model”, the cloud vendor is responsible for the “security OF the cloud,” which includes all the infrastructure that runs cloud services. While the major cloud providers go to great lengths to secure the infrastructure of their environment, it is up to the customer to secure the usage of the cloud services. The customer is responsible for “security IN the cloud.” Not all cloud consumers are aware of this and/or comprehend the significance. A seemingly small mistake can expose a lot!
‘Large enterprises with 5,000 or more employees report even greater multicloud adoption, with over half (57%) already using multicloud. Penetration among these companies is expected to soar to 80% in one to three years.’ – Nutanix Enterprise Cloud Index
Each cloud platform is unique: The configuration models differ, as do the APIs and services. Therefore, operational and security risks differ, making them difficult to understand and manage.
Tradition Has No Place in the Cloud
If you’re expecting traditional security practices to help keep your cloud-native apps secure, then you’re going to be disappointed and you’ll likely be putting your users at risk. For all its benefits, cloud-native has introduced complexity along with more overall lines of code. This is especially true if we consider DevOps technologies such as Infrastructure as Code and serverless computing.
‘Getting teams and organizations to embrace infrastructure-as-code (IaC) will certainly be a challenge. Teams that have been doing more traditional development, in which they do not touch much of the infrastructure, will need to learn some new skills. More importantly, they will then need to be allowed to use those skills. Operational governance will come into play here. Teams creating serverless apps will need more access to accounts to create resources that they may not have previously been allowed to create.’ is a key point to pay attention to on the report by New Relic in 2020
Traditional back-loaded security practices were already straining to keep traditionally built applications secure. When we apply these ‘outdated’ methods to cloud-native-based projects, one of two things happens:
- Productivity grinds to a halt because there’s so much friction in the workflow. Developers are forever chasing down vulnerabilities in code they wrote days or weeks before.
- In order to maintain throughput, the code security practices are “adjusted,” allowing more vulnerabilities to make it into the wild.
The problem is that back-loaded security practices that rely on tangential security experts to flag code for review introduce too much friction. It’s a long-tailed feedback loop, and developers understandably aren’t thrilled to re-work code from ages ago.
New Tech Requires A New Approach
Success in a cloud-native world requires a new approach – a Clean Code approach. And this new approach starts with an expectation that developers own the quality of their code. By quality, I mean developers should only be merging code that is fit for use and fit for change. To expand on this, fit for use means that it’s fit for its purpose, e.g., an application. Fit for change means that the code is also maintainable so that future developers can readily use it for new features without refactoring.
To many developers, code security is the domain of others – DevSecOps perhaps. This ideology must change. Modern software development is too fast-paced for this outdated mindset. Relying on downstream teams to catch security issues and bring them back days later for triage costs time and effort.
This is where the clean-as-you-code methodology becomes so important. While it may seem unfamiliar to many developers at first, clean-as-you-code is rooted in a developer-first approach that emphasizes code quality while also promoting developer growth and improvement.
Clean-as-you-code is based on two simple principles:
- Individual developers own the quality of their code, including code security
- Only code that passes the Quality Gate gets merged
While every developer likely strives to write clean cloud-native code, it’s really a monumental challenge without embracing a clean-as-you-code approach. With traditional methods, you’re making progress while stopping occasionally to clean up the problems and then it’s back to progress. It’s two steps forward and one step back. A traditional workflow like this isn’t efficient and it isn’t continually building toward a clean, secure app because real vulnerabilities are routinely merged and must be remedied later, assuming they eventually get detected. You’re playing with fire if your security process is based on removing merged vulnerabilities rather than keeping them out in the first place.
Developers Must Lead the Way on Cloud Native Security
Cloud-native development brings greater agility to enterprises, but it doesn’t come without risk. Applications built with cloud-native technologies introduce a bevy of new attack planes and vulnerabilities. Unfortunately, many organizations have failed to adjust and continue to rely on traditional security best practices that are insufficient to support modern application development practices.
This leaves a gap, and gaps mean unnecessary risk. Developers must take the lead in protecting their cloud-native apps. Coding mistakes are the primary cause of breaches – and developers are in the best position to identify and fix those errors. A clean-as-you-code approach enables developers to take charge of all aspects of their code security and build better, safer software.
Are you using clean-as-you-code or similar approaches to ensure higher security for your production software? Share with us on Facebook, Twitter, and LinkedIn. We’d love to know!
Image Source: Shutterstock
MORE ON CODING:
