Security tooling has a reputation problem with developers. Alert too early and you're noise. Gate too late and you're a blocker. So where's the sweet spot?

That was the central question I explored with Anna Daugherty on today's episode of the Naftiko Capabilities podcast. Anna, who does AppSec at Arnica, brings a unique perspective — she comes from the API design-first world at Stoplight, where she worked extensively on spectral rules and governance. That background in developer experience and standards of excellence now informs how she thinks about application security.

What Is AppSec, Really?

At its core, application security is about identifying vulnerabilities — secrets in code, insecure open-source dependencies, compliance gaps — before they reach production. And that urgency is well-founded: Anna cited an industry average of 200 days to remediate a vulnerability once it's live in production. The entire philosophy at Arnica is preventative. Find the problem early. Fix it while the context is still fresh.

But "early" doesn't mean "immediately." Anna broke down the developer timeline into three zones and made a compelling case for why two of them don't work.

Too early: the IDE. Developers are in flow, solving a problem. A security alert at that moment is just another Slack notification pulling them out of focus. It becomes noise, and noise gets ignored.

Too late: the CI/CD gate. A hard stop before production means triage mode — who introduced this? Who's going to fix it? Suddenly security is in the way, and the team is chasing problems instead of preventing them.

The sweet spot: the pull request. This is what Arnica calls the "pipelineless approach." Scans run when a developer is about to merge, right before code review. They're already pausing to have their work evaluated. Fixing a flagged issue at that moment is natural, not disruptive. The results speak for themselves: 72% of notifications sent to developers in Slack are fixed immediately, and 92% of all issues identified by Arnica are resolved before reaching production.

AppSec, API Security, and the Governance Thread

Kin pressed Anna on the relationship between application security and API security, and her answer was refreshingly grounded. The fundamental principles — governance, standards of excellence, developer experience, rule sets — are the same. The tools and outcomes differ, but the questions you're asking are identical. Her transition from API governance at Stoplight to AppSec at Arnica wasn't a leap; it was a lateral move across a shared problem space.

Beyond Engineering: Legal, Compliance, and Accessibility

One of the more striking points in the conversation was how Arnica's reach extends beyond engineering teams. Legal and compliance teams are using the platform too — particularly around software composition analysis, where licensing compliance is a real concern. A legal team might never log into an AppSec tool, but a well-structured report on licensing violations is immediately valuable to them.

This speaks to a larger theme Kin has been exploring on the Capabilities podcast: making security governance accessible to people outside of engineering. The tooling shouldn't live exclusively inside the pipeline. Its insights need to travel.

Governance Is Always the Question

When Kin asked what's actually changed in the developer workflow, Anna's answer was pointed: not much. Vendors will always try to sell you something shiny and new, but the reality is that developers want to work the way they want to work. The more an organization can support that in a flexible, sustainable way, the more effective the work becomes.

And the governance question? It never goes away. Regardless of the tool, regardless of the domain, governance is always the central challenge. The key is adapting it — different teams have different risk appetites, different regulatory requirements, and different internal knowledge about what actually constitutes a threat in their context.

Anna highlighted how health tech and fintech companies, operating under heavier regulatory pressure, tend to alert on lower-risk items that a faster-moving startup might deprioritize. It's not one-size-fits-all, and the tooling needs to reflect that.

Tribal Knowledge and Training the Tools

Perhaps the most forward-looking part of the conversation was around what Anna called "tribal knowledge" — the idea of capturing a team's institutional understanding and using it to train security scanning tools. If a team consistently dismisses a particular finding because they've determined it's not a real risk in their environment, that context should feed back into the system. An AppSec practitioner can then review those suggestions and decide what to apply.

It's a human-in-the-loop approach to tuning AI-powered security tools, and it addresses one of the biggest pain points in the space: false positives driven by generic rule sets that don't account for organizational context.

Rules at the Source

The conversation landed on a point that Kin has been circling for a while: governance artifacts like rules.md files living at the source code level. Anna's logic is clean — source code is the source of truth. Whether an enterprise uses GitHub, GitLab, Bitbucket, or some combination, everyone is using source control. If you can inject your governance rules at that layer, you get maximum coverage.

This is the intersection Kin is most excited about: shift-left enforcement meeting source-level guardrails, covering not just security but compliance, privacy, and broader operational governance.

Looking Ahead

Kin and Anna plan to continue the conversation, partnering on deeper explorations of how governance layers can adapt across domains, teams, and enterprises. It's a space where API governance, application security, and developer experience are converging — and the people building the tools are finally asking the right question: not "how do we enforce compliance?" but "how do we meet developers where they're most likely to act?"

The Naftiko Capabilities podcast is recordd via live conversations every Tuesday at 10:00 AM Eastern and Thursday at 1:00 PM Eastern. Join as a panelist or listener — all are welcome.

‍