In a perfect world, software developers would not only have an innate understanding of security but be able to create bulletproof code from the get-go.
I have been working across the software development lifecycle for over 25 years, so I can say with confidence that we don’t live in a perfect world.
In 2021, a survey of DevOps and IT professionals revealed that roughly 80% of companies admit to not managing their infrastructure secrets well. With the myriad of secrets that software teams manage, it becomes a herculean task to keep track of all of those secrets at a granular level.
As a result, developers often store secrets in plaintext files and other formats to make them easily accessible – but if they’re accessible to devs, they’re also accessible to attackers. Unattended secrets such as database credentials and API keys open a security backdoor, and the payoffs for bad actors are bigger than ever. According to 1Password’s “Hiding in plain sight” report, organizations that experience secrets leakage lose an average of $1.2 million in revenue.
Developers often assume that security is in someone else’s domain – but it’s developers who create the code. Devs should have a more active role in security management. That means being proactive about security and preventing vulnerabilities from being introduced from line 1 into production.
In this article, we’ll talk about this “shift-left philosophy” and how developers can take a more active role in application security.
What does shift left mean?
The diagram below shows the traditional software development lifecycle from initial planning to production and beyond. Traditionally, DevOps teams apply security in production. But developers don’t need to wait until an application goes through a last-minute security review.
Instead, they can treat security as a first principle, partnering with DevOps and SecOps teams to implement security measures very early in the software development lifecycle. By doing so, devs can catch potential vulnerabilities and security issues before they have a chance to cause problems further down the line.
For example, consider testing, QA, and performance activities. Traditionally, devs would finish their basic unit tests and serve code up to some other group for more extensive testing, who would volley it back with whatever issues they find.
This dev-tennis would continue until an acceptable quality threshold is passed, ultimately slowing down any momentum through wasted time and effort. Shifting left empowers the developer to test through automation so they can get immediate feedback, resulting in faster delivery and a higher-quality product.
This doesn’t mean that security is still a one-time concern. Moving to the left means applying security at every step of the development process, even after production.
How to shift your application security to the left
When devs try to move to reactive security and embrace the shift-left paradigm, software like 1Password Developer Tools can help us take more ownership of security – without compromising efficiency. Regardless of the tools you choose, here are some practical steps you can take to get started.
Eliminate plaintext secrets in your code
Occasionally, containers ship with unchecked vulnerabilities. Sometimes they’re malicious, and sometimes they’re just accidents, but regardless it exposes secrets hardcoded into code or plaintext configuration files. That’s a giant cyberattack opening, and it leaves the entire application vulnerable.
Instead of hardcoding secrets, devs can store them securely in encrypted vaults and access them in their code with references that are replaced at runtime. There are plenty of tools that can manage those secrets directly in the terminal or IDE of the dedicated security professional, so that the developers can’t introduce those vulnerabilities in the first place. When you go about choosing the secret management tool for your application, make sure it checks a few boxes:
- It conforms to AES-GCM encryption standards.
- It interfaces with your IDE so developers know straight away which placeholder to use, never tempting them to put the secret in the code in plaintext.
- It isn’t easily accessible by team members who aren’t versed in these security risks.
Ensure parity between environments
Likeness between different environments is critical as it ensures that your apps work similarly in all environments, including the final production release and the earliest prototypes. Without parity, you can’t ensure that the app can work in every context, and you can’t ensure the application’s overall quality.
For developers, ensuring parity means building test environments as closely as possible to what’s on production so their testing scripts are compatible with both contexts.
Secrets management helps drive better testing by increasing parity between environments and enabling secure access to the application infrastructure and related microservices. It grants testers and developers secure access only to the portions of the infrastructure they need to know, helping them conduct better tests.
Modernize your SSH workflows
Developers often use SSH keys to push code to GitHub, access servers, and more. So why is it such a pain to set up new keys? (If you’ve ever forgotten your passphrase or accidentally pasted your private key into a client instead of your public key, you know what I mean.)
It doesn’t have to be such a pain. When setting up your secret automation workflow, find a tool that lets you easily generate, store, and use SSH keys without making you run ssh-keygen commands manually or storing unencrypted versions of those keys on disc. A trustworthy secret management tool is going to sync your SSH keys across devices and lock them behind two-factor authentication.
Automate infrastructure secrets in production
These obviously aren’t the only three vulnerabilities that developers can cause. A reactive organization would just roll with the punches, patching attack vectors as they’re discovered, or worse yet, exploited. But a proactive organization will ask, “How can I instill best practices in the developers to prevent problems before they materialize?”
Take Coca-Cola, one of the world’s largest companies. Despite their massive size, encompassing thousands of employees and vendors, they manage to keep their secret recipe secret!
How is that? Well, they’ve automated a significant part of their process, meaning that no one person has to oversee everything. Complex algorithms and functions run the manufacturing process, ordering secret packages (to which they’ve given the placeholder names of “Merchandise 1”, “Merchandise 2”, and so on) and mixing them properly.
Just like that famous example, your developers are crafting a winning product with secret ingredients – so let them pass the delicate security procedures to automated tools! Then, they’ll be able to collaborate on code without worrying that the sensitive credentials will somehow leak through the CI environment.
The vendors, the executives, and the floor workers at Coca-Cola have an unspoken contract with each other that guarantees the security of their secrets and the quality of their product. Similarly, you can have a straightforward “contract” between the devs, the DevOps crew, and the security professionals: Agree to give all the sensitive information automated placeholders so everybody can collaborate without needing access to the secrets themselves.
Another common attack vector is finding data unencrypted in transit. How can we make sure that if an intrusion occurs, the attackers would only be able to access encrypted bits of unreadable information? This is another solved problem.
The solution is generating, encrypting, and managing keys on the client. This way, those secrets are never left unsecured while being passed between client and server. Look for a tool that supports Transport Layer Security (TLS) by default, and preferably adds a custom layer of encryption on top, all computed client-side.
Shifting left = proactive security
Shifting left means implementing security measures earlier in the software development lifecycle. But this alone isn’t enough. Companies must transition from a reactive to a proactive security paradigm to truly shift left. If developers are to truly take ownership of security, writing secure code from the get-go is the first step. Security professionals must think more like planners, catching issues before they ever really exist.
Tony Myers
VP, Product Management
Tweet about this post