DevSecOps is all about better integrating security into the software development life cycle (SDLC). When combined with the desire to automate repetitive tasks, the inevitable conclusion is to put any repeatable testing tool into your app’s build pipeline. For any tooling that involves code analysis, it makes sense to sync up with existing testing workflows. That’s where CI comes in.

Ruby on Rails is one of the most loved combinations in tech. It’s a language and framework that’s accessible to people of varying skill sets and experience. Its maturity and widespread adoption shows with how much the core team and community care about security. Each release improves the framework's hardiness, but there's still so much we can do as developers to protect our applications.

It is clear a new technology is taking hold when it becomes impossible to avoid hearing about it. That’s the case with generative AI. Large language models (LLMs) like OpenAI’s GPT-4 and the more approachable ChatGPT are making waves the world over. Generative AI is exciting, and it’s causing a real fear of missing out for tech companies as they try to match competitors.

In 2013, hackers breached an HVAC provider’s network, giving them access to 40 million credit and debit card numbers from their biggest client: Target. It took years to repair the damage. Relying on third-party vendors is necessary but still presents a cybersecurity risk. How will the companies handle your clients’ data? How vulnerable are they to being hacked?

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.