“If you know the enemy and know yourself, you need not fear the result of a hundred battles.
If you know yourself, but not the enemy, for every victory gained you will also suffer a defeat.
If you know neither the enemy nor yourself, you will succumb in every battle”

-Sun Tzu

We continue our journey in breaking down application security so that anyone can do it without hiring expensive teams of employees. We start by what should always come first, which is understanding your application before you understand your security.

In the pilot of our series on understanding what Application Security really was, we broke down appsec into its core components, starting from understanding context. So what does that really mean? This article will explore what it means.

Have you ever been in a room where you ask a question and everybody looks like this?

Well that seems to be more common these days in the era of coding agents. Less and less people seem to understand what’s going on, and we’re all just vibing out here:) So let’s explore what it means to know and understand something!

Know Your Enemy

Many times security professionals will say to each other or put in their job postings, “Be able to think like an attacker”. Now what does that really mean? They’re all saying to place yourself in the shoes of an attacker that wants to attack something in particular. What does that consist of? We’ll explore this in a later post on Threat Modelling, but what you do need to know is that attackers are definitely trying to get to know you. Dedicated attackers will study your company, the application, and know exactly where it hurts you and will do everything they can to hurt you where it actually hurts

Know Yourself

Application Context is really about how well do you know the application that you’re trying to protect. If you don’t know at the very least of what to protect, you’re kind of cooked.

Is it your customer’s data (you have some sort of regulatory obligation to protect the data)? Is it your servers hosting your application (do you mind if cryptocurrency mining software sits with your application)? Is it your internal planning documents?

You have to position yourself to know what is valuable to your business and make steps towards protecting that at all costs.

For Startups

For small startups, I would hope that you know what is worth protecting. If you don’t because you’re vibe coding without understanding what your code is doing, then I would hope/urge that you could start today as security comes from knowing what you’re trying to protect.

Counter-intuitively, for startups that don’t have the luxury of security teams, you’re actually ahead of the game because you know what’s important. Don’t lose that advantage.

For Enterprises

In big organizations, from a software engineering perspective in a bygone era, you would have written the code yourself and you would've known everything that is going on, but things still went wrong. That’s okay! It’s natural to know how your application functions, AND make mistakes. It’s mostly because we want the business logic to work so that we can focus on increasing the business, which is what the job of a software engineer is to focus on. This is where security professionals came in, tried to understand the code with the engineer who wrote the code, so they can understand how to read the code, what the code is actually supposed to do, and where it can go wrong. This is representative of a healthy relationship between software teams and security teams.

We are now in the era of agents that write the code for you based on your thoughts written down in prompts. It’s now the job of the engineer to know how well they put their thoughts down, to architect it well enough, and the coding agents can take over and write the code. The software engineer just tests that the code works, and voila! Business is booming!! So how do we secure the app now? What happens when the security engineer comes in and asks, “hey, how does this 100,000 line app work?” or “what was this piece of code supposed to do, again?”, to which the response would be…

The developer’s job shifts from knowing every implementation detail to making sure the system behaves the way they intended. It’s a perfectly fine tradeoff, but the security engineer still needs that context, so the security engineer asks, "How does this application work?" to which the answer becomes increasingly, "I'm not entirely sure. The agent built most of it".

Now the security engineer goes in with their claude code, and starts digesting the application bit by bit. They spend four hours carefully crafting the context, and analyzing, but during that time the coding agent has shipped three more features.

The security engineer just finished understanding yesterday’s application.

Security used to drink from a cup, but now we’re standing in front of a fire hose.

Tradeoffs

There are always tradeoffs when it comes to any decision or action. (BONUS LIFE TIP: assessing tradeoffs is really important it comes to big life decisions/actions, not just security!)

For Startups (w/o security staff)

Tradeoffs for startups without security teams look different from organizations with security teams. The tradeoff for startups is really just about time and cost.

Do you spend more time on finding vulnerabilities or do you spend more time on feature development? Do you spend money on someone to secure your app, or do you allocate your run way to increasing business (marketing, devs, infrastructure, etc.)? Many tradeoffs but it boils down to time and cost.

The ideal scenario here is a software engineer that has a strong security background that can check their logic as they code, however this is not usually feasible. We have to accept the tradeoffs of time or money.

For Enterprises (w/ security staff)

Software engineers, and their teams, might know all the nuances of the codebase of their own applications. They know (or should know) how every line of logic works, so they’re uniquely positioned to relay “perfect information”.

However, there is always going to be information disparity when working with multiple parties.

Security engineers don’t have the luxury of the “perfect information” because they didn’t write the code. They’re usually pressed for time because they’re juggling other parts of the company and securing other things besides just one application.

There are then 3 options for the security engineers/analysts:

1. Read all of the code themselves, line by line. This is costly in terms of time, and might still need help understanding from the devs the why, not the what/how)

2. Be part of the code writing process from the beginning. I’ve seen two mechanisms in terms of how this happens. Either security analysts are pair programming with the developers, shoulder surfing while they write the code and ask questions or I’ve seen “security champions” that sit with the developer teams and approve pull requests as the last approval mechanism. This is costly in terms of money because you now tie security personnel directly to a developer/team and it’s some multiple the cost of just the developer/team.

3. Understand the context from the developers. Because there is time pressure to secure applications, and security is retrofitted on to teams, what ends up happening often is that security engineers are given the responsibility to skim through for potential security flaws after getting some context from the devs, but ultimately might miss some. This often ends up as zero-days and it could be exploited later down the road and the security engineering teams may get blamed for the miss. It’s really no one’s fault at the end of the day. It’s like playing telephone, where information slowly decays and is lost over many parties and periods of time. No one has perfect knowledge, and time is of the essence. This is costly from the financial repercussions of security misses.

In most teams and organizations I’ve seen, option 3 is the one usually taken and it often forces teams to accept tech debt/security drift and try to make up for it in other areas to hedge the risks taken like Incident Response/Threat Detection or buying a bunch of tools to help with this process like SAST/DAST/IAST (mentions of those specifics are not confined to those specifics).

The ideal scenario here is the strong security engineer who has perfect context of the application, but that’s usually not feasible. We have to accept tradeoffs: time, money, or security misses.

Conclusion

From our home analogyin our last article, we understood applications are like homes that need proper maintenance. But how do you fix or maintain a home that you don’t really know? To make matters worse, your home is constantly being grown. We need to take matters in to our own hands and be dynamic with our methodologies along with our growth.

Startups: keep up on knowing and understanding your application. Understand exactly what you want to protect and focus your efforts on ensuring that those portions are locked down. Apply the methodologies that I discuss in future posts to your own application development.

Enterprises:

• same as above and

• Software engineers (and small startups) you should be maintaining a doc on context within your codebases labelled something like architecture.md or separated and maintained docs of certain parts of the codebase.

• Security Engineering should consist more of:

  • really trying to understand the application down to its last detail

  • using agents to help you with the above point (we’ll talk more about the roles of agents and creating proper agents in the future)

  • working with automation folks to create automation around your insights

Pigeon is a NYC Cybersecurity Services company, specializing in Application Security. If you or anyone you know needs application security services, please reach out to me at david@pigeonlabs.ai. We’re willing to work with you near and far!