Fortency · Field Guide

Product & Application Security Program

A practical, risk-based framework for small, growing teams.

Product & Application Security Program

A Practical, Risk-Based Framework for Small, Growing Teams

A field guide from Fortency — written by an experienced security practitioner who builds and tests these programs for a living. Free to use; no strings.

Overview

A security program is fundamentally a way to measure and quantify risk for your product. It is not a single tool or a one-time audit — it is a living system that scales with your team, your product, and your threat landscape.

Build it on three principles:

OWASP alignment: This framework is directly informed by two foundational OWASP projects — the Software Assurance Maturity Model (SAMM), which gives you a roadmap for building and improving your security program iteratively, and the DevSecOps Guideline, which covers embedding security controls into your CI/CD pipelines. The staged approach here mirrors SAMM's philosophy: you do not need to achieve maximum maturity in every category at once.

Recommended Program — Staged Rollout

Implement in order. Each stage builds on the last.

Stage 0 — Software Composition Analysis (SCA) + Secrets Scanning

Control: Know what's in your code before anything else — the third-party libraries you depend on and any credentials that may have been accidentally committed.

These are the fastest, cheapest wins in the entire program. Most breaches don't originate from custom code — they exploit known vulnerabilities in open source dependencies or leaked credentials. SCA scans your dependency manifests (package.json, requirements.txt, etc.) against databases of known CVEs. Secrets scanning monitors your repository history and every new commit for accidentally committed API keys, tokens, and passwords. Both run automatically and require minimal configuration.

If your team is using AI coding assistants, pay extra attention here — AI-generated code is more likely to introduce insecure dependencies or accidentally inline credentials. Get this layer in place before anything else.

SCA tool options:

Secrets scanning tool options:

Typical cost: $0–$100/month | When to start: Immediately — before any other stage

Stage 1 — Static Application Security Testing (SAST)

Control: Automated scanning of your application source code on every commit to catch vulnerabilities before they ship.

SAST tools analyze your code structure and data flows to flag injection flaws, insecure patterns, and common vulnerability classes mapped to the OWASP Top 10. Traditional SAST works by matching code against known patterns — fast and useful, but limited to what it's been trained to recognize. Claude Code Security extends this with AI reasoning, catching complex vulnerabilities that pattern-matching misses entirely.

Start in audit-only mode so findings appear as reports rather than blocking your deploys. Get comfortable with the signal before turning on enforcement.

SAST tool options:

AI-powered option — Claude Code Security (Anthropic) Claude Code Security reads and reasons about your codebase the way a human security researcher would — tracing data flows, mapping how components interact, and catching business logic flaws and broken access control that rule-based tools miss. In testing it identified over 500 previously unknown high-severity vulnerabilities in production open-source codebases, including bugs that had evaded expert review for decades. Every finding goes through multi-stage self-verification before surfacing, and nothing is applied without your approval.

Two entry points:

Currently in limited research preview for Enterprise and Team customers. Use it alongside a traditional SAST tool — it's a reasoning-based complement, not a drop-in replacement.

Typical cost: $0–$300/month (SAST) + Claude API usage | When to start: After Stage 0 is in place

AI-assisted remediation — Pixee (pixee.ai)

Pixee sits downstream of your scanners and automatically triages findings from SAST, SCA, and other tools, then writes production-ready code fixes delivered as pull requests. It ingests findings from SonarCloud, CodeQL, Semgrep, and other major tools, cuts noise aggressively, and generates fixes your developers can review and merge. For a small team drowning in scanner alerts with no dedicated security staff, Pixee is a practical way to close the loop between "finding detected" and "vulnerability fixed."

All-in-one option — Aikido (aikido.dev)

Aikido is worth considering as an alternative to assembling the Stage 0 + Stage 1 toolstack separately. It consolidates SAST, SCA, secrets scanning, container scanning, IaC scanning, CSPM, and DAST into a single platform with a free-forever developer plan and flat-rate pricing that scales well for small teams. If managing multiple point tools feels like too much overhead, Aikido is a strong consolidation option — trading some depth in any individual category for broad coverage and significantly less operational complexity.

Stage 2 — Cloud Infrastructure Benchmarking (CSPM)

Control: Continuously compare your cloud configuration against CIS Benchmarks — industry-standard hardening guides — to surface misconfigurations before an attacker finds them.

Common findings include open storage buckets, overprivileged IAM roles, unencrypted databases, and resources accidentally exposed to the public internet. These tools run automatically and produce a prioritized list — you don't need security expertise to get started. Focus on Critical and High findings first; leave lower severities until your team has the bandwidth.

Tool options to evaluate:

Typical cost: $0–$500/month | When to start: After Stage 1 findings are being reviewed regularly

Stage 3 — Runtime Intrusion Detection

Control: Monitor your production environment in real time to detect active attacks as they happen, rather than discovering breaches after the fact.

For a small team, the goal here is visibility — knowing something unusual is happening — not a 24/7 response capability. Start with managed or cloud-native options that do the heavy lifting for you. Plan to spend a few weeks tuning alert thresholds. Too many false positives will cause your team to stop paying attention, which defeats the purpose.

Tool options to evaluate:

Typical cost: $200–$800/month | When to start: After Stage 2 findings are being remediated consistently

Stage 4 — Dynamic Application Security Testing (DAST) + AI Pentesting

Control: Attack your running application to find vulnerabilities that static code analysis can't see — auth bypasses, injection flaws, and runtime behaviors that only manifest when the app is live.

Traditional DAST tools probe a running application from the outside, simulating an attacker without source code access. They're useful but generate significant false positives and miss context-dependent vulnerabilities. Shannon takes this category significantly further by combining source code analysis with live exploitation — it attacks your running application with knowledge of your codebase, proving vulnerabilities are actually exploitable before reporting them. This "proof by exploitation" approach virtually eliminates false positives and gives you continuous testing coverage between annual professional pentests.

We recommend Shannon over a standalone DAST tool. It closes the gap between how fast you ship and how infrequently formal security testing happens.

Shannon (Keygraph — Open Source) Shannon is an autonomous AI pentesting framework built on Anthropic's Claude models, available as open source (AGPL-3.0). It maps your application's attack surface, launches specialized AI agents targeting different vulnerability classes, executes real exploits, and only reports findings with a working proof-of-concept. You can integrate it into your CI/CD pipeline to run against every build or release.

Before you use Shannon:

Traditional DAST tools (if Shannon is not the right fit):

Typical cost: Shannon — open source + Claude API usage; traditional DAST — $0–$500/month | When to start: After runtime monitoring is stable

How Fortency helps here: our Security Pulse service runs this continuous, source-aware testing for you on a subscription — quarterly, human-validated findings your engineers can act on, without standing up and babysitting the tooling yourself.

Stage 5 — Penetration Testing (Grey-Box)

Control: Bring in a professional firm to simulate a real attacker with partial knowledge of your environment, producing a confidential report of findings and recommended fixes.

By the time you reach this stage, Shannon will have filtered out the common, easily discovered vulnerabilities. Your pentest engagement can then focus on deeper logic flaws, chained attack paths, and business-layer weaknesses that AI tools still miss — you get significantly more value from the same investment. A grey-box test, where the tester is given limited context about your system, offers the best return for a small team.

The pentest report is also a tangible artifact you can share with enterprise customers, auditors, and investors as evidence of due diligence.

Service options to evaluate:

Typical cost: $15K–$60K per engagement | Cadence: Annually or after major architectural changes

How Fortency helps here: we deliver a fixed-price, audit-ready Penetration Test built for exactly this — human-led, exploitation-based, mapped to SOC 2 criteria, and shareable with auditors and enterprise buyers. Retest and letter of attestation included.

Additional Controls to Consider

These categories are likely out of scope for an early-stage program but worth knowing about as your team and product mature.

Bug Bounty Program — invites vetted security researchers to find and responsibly report vulnerabilities in exchange for rewards. Running one well requires readiness that takes time to build: a triage process for incoming reports, clear scope definitions, consistent remediation throughput, and a solid understanding of your own risk posture. Opening a program too early creates more noise than value, and mishandling a researcher's report can cause reputational damage. When you're ready, start with a private, invite-only program on a narrow scope. Platforms to evaluate: HackerOne, Bugcrowd, Intigriti.

Web Application Firewall (WAF) — sits in front of your application and blocks common attack patterns in real time. Most cloud providers offer one (AWS WAF, Cloudflare). Useful as a compensating control but not a substitute for fixing underlying vulnerabilities.

Container & Image Scanning — if you run in Docker or Kubernetes, scanning container images for known vulnerabilities is a natural extension of SCA. Trivy (open source) and Snyk Container both integrate well with existing pipelines.

Supply Chain Security — goes beyond SCA to verify the integrity of your build pipeline itself, guarding against malicious packages and dependency confusion attacks. OWASP CycloneDX and Dependency-Track are the primary frameworks here.

Interactive Application Security Testing (IAST) — instruments your running application to detect vulnerabilities during normal operation or testing. IAST agents sit inside the application at runtime, observing code execution and data flow as tests run — giving you the accuracy of SAST with the runtime context of DAST, and far fewer false positives than either. The tradeoff is deployment complexity: agents need to be installed into your application runtime, which is straightforward for traditional servers but adds overhead in containerized environments. Coverage is also tied to test suite quality — IAST only sees code paths your tests actually exercise.

Tools to evaluate:

Security Awareness Training — OWASP SAMM emphasizes developer security education as a foundational practice. Secure Code Warrior and Snyk Learn offer developer-focused training that compounds the value of every other control in your program.

Building the Program Iteratively

Every control you add will generate findings — vulnerabilities to triage, alerts to review, reports to work through. The biggest risk for a small team is activating too much at once and burning out before the program delivers value.

A practical sequence:

  1. Start with SCA and secrets scanning — low effort, immediate risk reduction.
  2. Deploy SAST (including Claude Code Security if available) in audit-only mode before enforcing build failures.
  3. Run cloud benchmarking and fix Critical and High issues before worrying about lower severities.
  4. Add runtime monitoring and spend a few weeks tuning thresholds before treating any alert as urgent.
  5. Run Shannon against staging to get continuous coverage before scheduling a professional pentest.
  6. Bring in a professional pentester when Stages 0–4 feel stable — your engagement will be more focused and the report more actionable.

Simple metrics to track:

Metric Initial Target
Time to fix Critical vulnerabilities < 7 days
Time to fix High vulnerabilities < 30 days
Is the vulnerability backlog growing or shrinking? Shrinking
Are alerts being reviewed regularly? Yes — even weekly is a start

References & Further Reading

OWASP Resources

Industry Standards

AI Security Tools

Want a hand implementing this?

This framework is yours to run on your own. But if you'd rather not build it solo, Fortency works with startups at every rung of this ladder:

→ Book a 15-minute call: [your link] · See a sample pentest report: [your link]

No pressure — the guide above stands on its own. We're here when you want a partner for the journey.

© Fortency · This guide is free to use. Framework aligned to OWASP SAMM & DevSecOps.