What AppSec is not good at

Application security has done a lot of good. It also has habits that make engineers wary of it. You will be tempted by each one, usually under pressure. Knowing them by name makes them easier to resist.

Blocking releases

Stopping a release feels like the strongest thing a security person can do. Sometimes it is right. More often it teaches teams to bring you in late, or not at all. If you find yourself wanting to block a release, ask why you are only hearing about this now. That is usually the real problem.

• Prefer a fix with a date over a block.
• If you must block, explain the risk in plain words and offer the smallest change that would unblock it.
• Afterwards, find out how to get involved earlier next time.

Tool sprawl

Each new scanner promises to find what the others miss. Each also brings its own dashboard, its own false positives and its own integration to maintain. Several tools reporting the same issue in different words is noise, not coverage.

• Before adding a tool, name the gap it fills and the tool it might replace.
• Count the time to tune and maintain it, not just the licence.
• Send results to one place developers already look.

Reports nobody reads

Long reports full of findings, colour-coded by severity, often go unread. Not because people do not care, but because nothing in them tells a busy reader what to do next.

• Lead with the one or two decisions you need.
• Write for the person who will act, in their language.
• If nobody asks about a regular report, ask whether it should still exist.

Rule of thumb:The best compliment an AppSec person can get is a developer saying they asked security early because it made their work easier.

Six months in, you know more about this codebase than most people outside the teams that wrote it. Use that to help them ship safely, not to stand in their way.