Imagine a team building a simple feature: an endpoint to let users download their invoices. The implementation is straightforward: check the user is authenticated, fetch the file, and return it. It passes code review, tests are green, and it ships. A few weeks later, someone realizes you can tweak a parameter and download another user's invoice, and the team now has to rush to fix this security issue.

No software engineer sets out to write insecure code. However, stories like this one keep happening, and if you think about it, for the team building the feature, nothing "looked" insecure during development, and that is because no one had clearly defined what secure meant for that feature in the first place.

This is the real gap AppSec engineers fill. Their job isn't just to run tools and share the findings with engineering, but to define what "Secure" means in the context of what is being built by helping teams ask the right questions early: Who should have access to this data? What could go wrong? How might someone abuse this flow? By identifying relevant threats and defining the right mitigations upfront, AppSec turns security from guesswork into something concrete, something teams can actually build against, verify, and test.

The Value AppSec Engineers Add

At its core, everything AppSec engineers do revolves around two goals:

1. Define "Security": The meaning of the word "Secure" is incomplete until we specify what we need to be secure from (the threats), and what we can do about them (the mitigations). This applies at every level, from full systems to individual features to single pull requests.
2. Enforce "Security": Based on the identified threats and mitigations, AppSec ensures they are consistently applied. This means using the right combination of processes and tools to prevent new issues, detect existing vulnerabilities, and help teams fix them effectively.

AppSec is a Force Multiplier, not a Gatekeeper

AppSec works closely with engineering, platform, and other teams to apply the processes and tools needed to achieve these goals across the SDLC. But doing this well requires balance. If AppSec introduces friction, slows teams down, or becomes a gatekeeper, it quickly loses trust and becomes counterproductive. Effective AppSec enables teams to move fast while staying secure, not the other way around.

How AppSec Gets This Done

To achieve these goals while maintaining the right balance, AppSec applies a combination of processes and tools across different stages of the SDLC. Here are the most important ones:

Threat Modeling

A Threat Model focuses on answering 4 main questions:

1. What are we working on? → Scope
2. What could go wrong? → Threats
3. What could we do about it? → Mitigations
4. Did we do a good job? → Verification and Testing

And the answer to these questions is how we achieve the "Define Security" goal for what is being built. Hence, adding "Threat Modeling" to the Design stage of the SDLC for new projects is an essential component of any AppSec program, and it also drives many subsequent processes and tool choice.

For more details about threat modeling, you can check the Threat Modeling Handbook series.

Security Review Process

Threat Modeling is ideally the first phase of a "Security Review Process". One of the outputs of the threat model should be a testing plan to verify that the threats identified are properly mitigated, which should be performed during the "Testing" phase.

Mitigations can be verified in different ways, including:

• Code Review
• Security Testing (e.g. using Burp Suite)
• Security tools (e.g. using SAST)

Also, some mitigations should be covered by continuous tests (e.g. unit or integration tests) to make sure they aren't broken by future code changes, which should also be covered in the testing plan.

In practice, AppSec and engineering can't review every project due to time constraints. Instead, we should use a set of criteria to prioritize work based on risk and complexity. Tuning these criteria is critical; AppSec should focus on the highest-impact areas without taking on more reviews than it can handle and becoming a bottleneck.

Code Review

Besides the Security Review process for new projects, we also need to review individual pull requests that meet specific criteria (e.g. pull requests adding or modifying new endpoints) to make sure they don't introduce new security issues. This usually follows the same steps as the Security Review process (threat modeling followed by security testing), but on a smaller scale. As with project-level reviews, tuning these criteria is important to focus on high-impact changes without creating unnecessary friction.

Security Tools

The use of security tools to automate verifying threats are mitigated is important for efficiency, and for coverage (e.g. code not covered by the review process is covered by tools). However, there are 2 common pitfalls AppSec should avoid with security tools:

1. Relying on security tools to "Define Security" and prioritize work. Security tools usually can't consider the context and business logic of the application, hence they can generate a lot of false positives or findings of low priority. We should always start with "Threat modeling" and then select and configure the security tools that cover the mitigations we identify, to make sure we focus on the high-impact findings in the context of the application.
2. Sharing untriaged findings with engineering. Sending too many false positives, incorrect severities, or non-exploitable security issues to engineering is a great way to lose their trust. AppSec should always perform triage of any finding before sending it to engineering to ensure the issue is reproducible, the severity is accurate, and suggest a fix whenever possible.

With that in mind, different tools can be used to detect security issues in the multiple layers of the application. Also, we need to mix between incremental scans (e.g. PR scans) and full scans (e.g. scheduled daily or weekly) for best results. Here are some of these tools:

• SAST: Static code scanning helps detect specific types of vulnerabilities affecting the application code, mainly the ones related to using a dangerous function/sink (e.g. use of a function that can lead to SQL injection).
• Unit and Integration tests: Engineering teams already use unit tests and integration tests, and they are a great fit for testing the mitigations related to the application business logic (e.g. authentication and authorization), which are typically not covered by SAST.
• SCA: Applications need open source packages (e.g. npm or pip packages) to run, and these packages could be affected by some vulnerabilities. Hence, we should be scanning these packages for known vulnerabilities. It is recommended to use tools that support Reachability analysis to make sure we are focusing on the vulnerabilities that are reachable and potentially exploitable.
• Container vulnerability scanning: Similarly, if your application is running on a container, this container could have some packages with known vulnerabilities, so we should be scanning the container images used and prioritizing fixing the ones that are potentially exploitable.
• Cloud config scanning: If the application is running on a cloud service, scanning the account for misconfigurations (e.g. an S3 bucket with customer data set to allow public access).

For more details about security tools, you can check https://devopsroadmap.io/growth/devsecops/

Pentests and Bug Bounty

Besides the internal pentesting AppSec performs as part of the security review process, it is recommended to schedule periodic pentests performed by vendors, as well as start a bug bounty program when the AppSec program is mature enough to handle it. Both external pentests and bug bounty act as a safety net to help detect issues missed by our tools and processes, and as a feedback loop to use these misses to improve our tools and processes (e.g. add more tests to our scanning tools, or add more threats to our threat modeling library).

People

AppSec should also be investing in promoting a health security culture within the engineering team, which can be done through:

• Providing periodic training sessions focused on AppSec.
• Providing resources, e.g. an AppSec wiki showing the most important threats and their mitigations in our applications.
• Building relationships and communication channels with stakeholders.
• AppSec champions program, where software engineers interested in security can learn more, and act as advocates for security within their team.

AppSec Skills

Being able to perform the processes and use the tools to run a successful AppSec program requires a set of skills that spans multiple domains, including:

• A strong understanding of common security issues and vulnerabilities (e.g., OWASP Top 10).
• Solid knowledge of system architecture and application design.
• The ability to apply that knowledge during threat modeling by mapping relevant risks to what is being built.
• Comfort reading and writing code, enabling effective code reviews, validating mitigations, and contributing fixes that make systems secure by default where possible.
• Hands-on experience with pentesting and security testing.
• A good understanding of the underlying infrastructure, including cloud platforms and CI/CD pipelines.

Conclusion

When done well, AppSec doesn't slow teams down. It removes uncertainty, reduces rework, and helps engineers build with confidence. That's what makes it a force multiplier.

If you're an engineer, this means security shouldn't feel like a last-minute hurdle; it should be something you can design and build for from the start. If you're building an AppSec program, success isn't measured by the number of findings, but by how effectively you help teams prevent them in the first place. And if you're looking to become an AppSec engineer, your impact will come from how well you can bridge the gap between risk and real-world systems.

That's what AppSec engineers actually do, and why it matters.