application security

Back in 2023, I started writing an article about what I thought software engineers should keep in mind about application security. It wasn’t about tools, libraries, or techniques. It was about general ideas that could shape how they think about security while building software.

I never got to finish or publish it. Recently, I decided to revisit it, spending some time updating and expanding it with new content and perspectives I’ve acquired since then.

When we deploy software to production, we expect it to work as designed. We have tests, code reviews, security controls, and other practices that help reduce the likelihood of something going wrong. But as we’ve discussed throughout this series, none of these controls can guarantee that a system will never be compromised. There are things we don’t control, such as a security issue in an external service or API, or a newly discovered zero-day vulnerability in one of the dependencies we use.

If someone exploits a vulnerability, gains unauthorized access, or abuses legitimate functionality, would we know? And once we identify the problem, how prepared are we to investigate, contain, and recover from it?

When we think about securing an application, a lot of our attention goes to its code. We review changes, test functionality, manage dependencies, and look for vulnerabilities. That’s important work, but our application doesn’t go from a developer’s laptop to production by itself. There are repositories, build pipelines, artifact stores, cloud services, and other systems involved along the way.

Each of these components has its own access controls, configuration, dependencies, and opportunities for mistakes. Even if the application code is secure, weaknesses in the surrounding environment can still put the system at risk.

When we identify a security issue, it’s natural to focus on the bug itself: what is vulnerable, how it can be exploited, and how to fix it. These are important questions, of course, but they don’t tell us how bad the consequences could be. For that, we need to understand the application, its permissions, the data it handles, and what an attacker might be able to do after exploiting the weakness.

That’s a useful distinction to make when assessing risk. A vulnerability can be an isolated problem with limited consequences, or it can become the starting point for a broader compromise. The same type of vulnerability can present very different levels of risk depending on the surrounding context.

When it comes to security, there are a lot of things I’d love to have known when I started my career as a software engineer. Now, as an engineer focused on cybersecurity, there are things I’d like my product engineering colleagues to know.

There are books, videos, and other resources out there that can teach you about vulnerabilities, what they are, and how they can be exploited. Others teach tools and methods for scanning code, finding vulnerabilities, and fixing them. Some of these resources, usually the good ones, bring more than just technical expertise. They help develop an adversarial way of thinking, which is fundamental to understanding where weaknesses might exist, how attacks can happen, and how far they could go.

This post is the first in a series where I want to share some habits and perspectives that can help software engineers develop a strong security mindset.

Let’s talk about something that most developers and engineering teams don’t pay the necessary attention to. Do you have a process to update your application dependencies? How likely is it that your application could be compromised because of a vulnerable dependency?