Developing Safer Code to Protect Company Secrets in the Cloud – InApps 2022

Many organizations keep at least a portion of their data in the public cloud, if not most of it. As a result, there’s always an underlying risk of inadvertently compromising confidential information, such as API tokens, private keys, usernames and passwords — more often due to inadequacies or loose ends in their workflows and solutions.

Enterprises have often discovered these incidents after the fact through detection mechanisms that scan and flag public repositories for company secrets in the cloud. But these types of situations are too reactive and thus ineffective — they only alert you that “secrets” have been exposed after a breach has occurred.

Over time, we’ve seen such circumstances leading to high-profile security incidents at StackOverflow, Uber and, most recently, Shopify. In Shopify’s case, hackers were able to access the personal information of millions of customers. To avoid exposing their secrets in the public cloud, organizations must rethink the developer’s role in code security and consider using new tools to augment a developer-led security culture.

Stolen Secrets and Their Repercussions

When company secrets are exposed, cybercriminals can wreak havoc on organizations. They can compromise accounts, steal data and take systems offline in a matter of minutes. This puts customer data, infrastructure information, as well as overall brand reputation at risk. It also drains an organization’s pocketbook: The average total cost of a data breach increased by nearly 10% to $4.24 million in 2021, the highest ever recorded.

It’s not enough to be able to detect these leaks after the fact. The best place to detect possible user or system-level authentication credential leaks is at the very beginning of the development workflow, that is, your editor or the integrated development environment (IDE).

The Developer’s Role in Protecting Secrets

Despite what many believe, the majority of software security vulnerabilities are not malicious attacks. Rather, they’re the result of coding errors. This tells us that developers have a substantial impact on security. The integrity and continuity of the code they write and the code they source publicly is critical to securing company secrets.

But developers are busy and don’t have time to sift through all the false positives and error codes inherent in traditional code security tools. So, the road to mitigating stolen secrets must include tools that will not just change how and when issues are raised, but also change which issues are raised, too.

Solutions that allow developers to catch those mistakes beforehand are critical to an organization’s ability to protect its secrets. With actionable and highly contextualized feedback, developers can write safer code that resolves security concerns at the earliest possible moment. Most SAST tools raise issues for everything even remotely suspicious and let the auditors sort it out, but that way of thinking doesn’t make writing safe code any easier — in fact, it only convolutes the process.

Writing Safer Code Needs to Be Easier

Developers need tools that make writing safer code easier and more efficient. Static analysis checking tools help developers fix quality and security issues as they write code. Just like a spell-checker, these tools highlight bugs and security vulnerabilities and then suggest solutions to fix the issues before the code is committed.

Good linting or static analysis checking tools will deliver on several things. First, they will offer thorough bug detection that is based on an extensive rule database of common mistakes, tricky bugs and known vulnerabilities.

Think of this as a living, breathing public cheat sheet for developers to learn from others’ past mistakes and findings. Next, it will provide the developer context and rule descriptions to give them clear guidance as to what needs to be fixed and the best ways to fix it. It will also deliver rich documentation that teaches the developer coding best practices.

The point of these features is to empower developers to learn from their mistakes, and over time, rely less and less on the “spell-checking” tools. As a result, these devs can write clean code from the outset and accelerate their development cycles as a result.

Tactically, organizations will also want to seek out tools that offer consistent and instantaneous analysis that is 100% reliable every time. It’s best that these tools be compatible across the most popular IDEs, such as Eclipse, JetBrains IDEs, Visual Studio and VS Code, as well as a variety of programming languages. Lastly, ease of use and minimal configuration requirements will benefit companies seeking to improve their code security.

Conclusion

Organizations can’t allow the protection of their secrets to work backward. As we’ve seen play out more and more within the last several years, compromised accounts can lead to individual and resource-level consequences, like potential account hacks. It can also be detrimental to the confidentiality of a business’s customers, and today, we know that reputation is everything. Starting at the source — developing safer code from the start — is the best way to reduce the likelihood that a company’s most valuable credentials wind up in the wrong hands.

List of Keywords users find our article on Google: