cybersecurity

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.

Last week, Anthropic published an interesting post analyzing the cybersecurity capabilities of Z.ai’s open-weight GLM-5.3 model and comparing some of its security testing performance with Claude Mythos Preview. Anthropic’s testing found GLM-5.3 surprisingly close to Mythos Preview on some of the harder benchmarks.

A couple of weeks earlier, NIST’s Center for AI Standards and Innovation (CAISI) had published its own assessment. It described GLM-5.3 as the most cyber-capable open-weight model released so far, while estimating that its overall cyber capability still trails the current U.S. frontier by roughly four months.

The other day, I was talking with some former teammates who now work as software engineers at different companies, and the conversation turned to their relationships with their security teams. A familiar theme quickly emerged around the disconnect between security recommendations and the realities of their day-to-day engineering work. Sometimes it feels like we have come a long way as an industry, but many security teams still operate at a considerable distance from the engineers building and maintaining the systems they are trying to protect.