Developers work tirelessly to make sure their applications function without issues. Developers constantly program, debug, and reiterate. Rinse, wash, and repeat. During the development cycle, those software engineers do everything they can to pay close attention to all aspects of the process.
However, there's one area that some developers fall short on—security.
The most widespread security vulnerability is leaving secrets in code. Secrets are bits of code, often passwords, encryption keys, or API keys that enable the software to connect to third-party accounts, APIs, applications, or services. With the advent of CI/CD, hybrid clouds, web applications, and containers, secrets have become increasingly important to developers.
The pitfalls of leaving secrets in code
The answer to this question is really quite simple. Let's say your developers are creating an application that must communicate to Google services, via an API encryption key. One of your developers takes a shortcut and adds your Google API key in their code and then commits that code to GitHub.
Next up, a hacker gains access to your company's GitHub repository and locates your Google API key. They now have the means to access an API that should only be accessible by you. To make matters worse, that API key might also allow them to go the opposite direction and access your company network, via the application. All of a sudden your data (or your customer data) is at risk.
So simply by taking a shortcut, your software engineer has left you open to possible data theft and network attacks.
How can you do this?
You have to retrain your developers into thinking like security admins. Not that you have to tear them down and rebuild them such that they are forensic specialists, capable of hardening your servers and your network. No. What you need to do is get them to think about security in terms of where vulnerabilities begin—the code. And until your developers understand where their responsibility lies with security, they'll continue to keep placing secrets inside their code.
To do this, those developers need to closely examine two concepts: AppSec and DevSecOps.
What is AppSec?
AppSec is short for Application Security. The goal of AppSec is to improve the security of applications by finding and fixing security vulnerabilities at the application level. This idea begins at the design of an application and extends throughout the entire lifecycle of the application (even beyond launch).
In other words, your developers aren't only concerned about creating an application that works, but one that works and is secure. But how do you get them to start applying AppSec to their process? You outline best practices, which could include:
Establishing an AppSec security risk profile that identifies what vulnerabilities and weaknesses commonly occur in applications.
Work to eliminate all vulnerabilities and weaknesses listed in the security risk profile found within all code created by your developers.
Employ AppSec tools (such as Static Application Security Testing and Dynamic Application Security Testing) created to enhance the security of code throughout the lifecycle of every application.
Get your team trained not only with AppSec but with general security practices.
It’s important that your developers apply these best practices not only to the code they develop but all third-party code they use (such as libraries).
What is DevSecOps?
DevSecOps is the intersection of Security and DevOps. DevOps is a set of practices combining both software development and IT operations, with the goal of providing continuous delivery and the integration of high-quality, scalable software.
With DevSecOps, the idea of security is shared between both Development and Operations, to help build a more robust security foundation for all DevOps projects. DevSecOps not only requires everyone involved with security out of the gate, but it means automating portions of the security workflow, so the lifecycle isn't slowed down by security audits and mistakes.
Best practices for DevSecOps include:
- Automate early and often such that security controls and tests are embedded everywhere in the life cycle.
- Include code dependencies into the security automation mix.
- Think small, when employing Static Application Security Testing tools, by turning on one or two security checks at a time.
- Use automation security tools that integrate seamlessly into your pipeline (so developers aren't having to constantly exit out of their usual tools).
- Employ threat modeling and risk assessments before you migrate to DevSecOps.
Rinse, wash, repeat
It's absolutely crucial that your developers are constantly reminded how important it is to not leave secrets in code and to always keep application security in mind. Until that ideology is firmly implanted, they'll continue leaving secrets in their code and risk data loss or worse. Once your developers have a solid grasp on their role in the security lifecycle of the software they create, you might find them less prone to leaving secrets inside their code.
If you get stuck, you could always turn to a third-party development team that is well-versed in software development security. You could also educate your in-house developers in the ways of software security.