On March 7, 2023, Loom experienced a security incident caused by a settings change in their CDN. Even with extensive internal testing, the nature of the problem caused it to go unnoticed until the change landed in production. Their incident report is a great explanation of the issue itself, so I won't reiterate much of it here, but what I will look at is a related issue, and how static code analysis tools integrated into development pipelines could have prevented the issue.

For the last two years, we’ve been quietly building a new kind of static application security testing (SAST) solution that allows security and engineering teams to assess, prioritize, and remediate security risks and vulnerabilities in their code by what matters most - sensitive data. Today, we are officially announcing its release as an Open Source project, Bearer.

13M developers write 14K lines of code each per year, touching sensitive data 16,847,298 times per year. If you need to understand how important, but also how difficult, it is to pinpoint sensitive data risks in a modern application stack, that is the number to keep in mind. In an effort to better explain the urgency of data security, we went in search of tangible numbers and came up with those above. But, how did we end up with them? Let’s take a look.

In “Developers don’t care about (data) security!” I dive into why that title isn’t necessarily accurate, but what is true is that developers don’t care about compliance—and by extension privacy regulations. Not because they don’t care about the underlying issues, but because the rules are murky and confusing.

When people talk about data security, most of the time data privacy is in the following sentence. Even though they have many commonalities, they are different things. Both with physical practicalities in the real world, and digital nuances on the web.

Over the past two decades we have seen security get more and more granular, going deeper into the stack generation after generation, from hardware, to network, server, container and now more and more to code. The next frontier of this evolution is data, especially sensitive data. Sensitive data is what organizations don’t want to see leaked or breached. This includes PHI, PII, PD, financial data.

Now is the time to rethink how you manage data security. We’ve discussed the potential for breaches, financial ramifications, and loss of business in the past. These get your attention, but we’re well beyond that. No company is immune to these risks anymore. It’s the “how” that trips people up. How do you account for every line of code? How do you keep tabs on third parties? How do you ensure security teams aren’t in the way of developers?

I’ve heard the title of this article uttered in exasperation by more than a few CISOs. That can’t be the case though, right? Developers are some of the most paranoid cautious, security-conscious people I know. Compared to your average person, developers are far more skeptical when it comes to their personal data. Even as a CEO, those instincts from my time as a full-time dev persist.

Our core mission at Bearer has always been focused on improving the developer experience. As we’ve evolved, that drive narrowed in on enabling development teams to strengthen their data security posture, while still maintaining the pace and agility needs of modern software. In an environment where data breaches and leaks are increasing rapidly year over year, it’s vitally important to detect sensitive data risks before they happen.

Amazon’s Relational Database Service (AWS RDS) allows you to offload the responsibility of managing a database, but it also comes with the risk of another external dependency. Fortunately, AWS provides some tools and settings to help with this. When you combine your existing data security policy with the AWS tooling and the advice in this article, you'll be well on your way to managing risk more effectively. Let's dive in with 15 AWS RDS data security best practices.