Building an Application Security Program from Scratch: A 90-Day Roadmap

You've just been hired as Head of AppSec — or a VP of Engineering handed you an AppSec mandate with no budget clarity, no team, and a backlog of features shipping daily. Where do you start?

This is more common than the industry likes to admit. Most mid-market companies (100-2000 employees) have been shipping software for years before they get serious about application security. The developers are good, the product is real, but the security foundations were never deliberately built.

The following 90-day roadmap is opinionated and realistic. It's built for someone who has to show progress quickly, doesn't have infinite budget, and is working with engineers who have other priorities. Perfect is the enemy of shipped — focus on foundations first.

Before building anything, you need an honest picture of your current state. The instinct is to start scanning everything immediately — resist it. Scans without context produce noise. Context makes findings actionable.

Week 1: Asset Inventory

You cannot secure what you don't know about. Start here:

• Web applications and APIs — list every public-facing endpoint. What's in production? What's in staging? What's deprecated but still running?
• Dependencies — pull the dependency graphs for your major services. Get a rough sense of age and known vulnerability exposure (GitHub's Dependabot alerts are a quick start).
• Authentication surfaces — where do users log in? What handles sessions? Are there internal tools with weak auth?
• Data stores — what databases exist, what do they hold, who can access them?
• Third-party integrations — what external services does your app trust, and how?

Document this in a spreadsheet. It doesn't need to be beautiful — it needs to exist.

Week 2: Developer Interviews

Talk to your engineers before you start testing. Specifically:

• Where do they think the riskiest code is?
• What architectural decisions were made under time pressure that no one was happy about?
• Are there any known security issues that haven't been fixed yet?
• What's their current mental model for "secure enough"?

These conversations surface high-value targets faster than any automated tool. Developers know where the bodies are buried — they just haven't had anyone ask.

Weeks 3–4: First Scan Pass

Now run your first automated scan. This establishes a baseline — not a remediation list.

Use a DAST tool against your staging environment or production (with appropriate care). Configure it broadly — you want discovery, not depth, at this stage. Export the results and categorize findings by:

• Severity (Critical, High, Medium, Low)
• Type (injection, auth, config, etc.)
• Application / service affected

Don't try to fix everything yet. The goal is understanding the landscape. You'll use this data in Phase 2 to prioritize.

With baseline data in hand, Phase 2 is about building the infrastructure for a sustainable AppSec program and knocking out the quick wins your baseline surfaced.

Set Up Automated Scanning

Your first baseline scan was manual. Now automate it:

• Schedule weekly DAST scans against staging. This creates a rolling record of your security posture over time — essential for SOC 2 and enterprise sales.
• Add SCA to CI/CD. Dependency scanning on every pull request catches vulnerable packages before they merge. Tools like Dependabot, Snyk, or Trivy integrate in an hour.
• Configure severity thresholds. Critical findings should block merges; High findings should create tickets automatically. Medium and Low go into a backlog triage queue.

This is the most important infrastructure you can build. Automated scanning running continuously is worth more than a manual pentest that runs once a year.

Remediate the Quick Wins

From your Phase 1 baseline, pick the 5–10 highest-severity findings that are genuinely fixable in a sprint. These should be:

• High confidence (not ambiguous false positives)
• Bounded scope (one service, one endpoint)
• Clear fix (not architectural rewrites)

Work with the engineering team to fix these. Ship them. This does two things: it reduces actual risk, and it builds credibility with engineering. The worst way to start an AppSec program is to dump 200 findings on a team and disappear.

Build a Triage Process

Security findings need to go somewhere. Build a minimal triage process:

1. Finding in — scanner produces a finding
2. Triage — verify it's real, assign severity, assign owner
3. Ticket — create a tracked issue in Jira/Linear/GitHub Issues
4. Fix — engineer resolves it
5. Verify — re-scan confirms it's gone
6. Close — ticket closed with resolution notes

This doesn't need custom tooling. A Jira project with five columns works. What matters is that every finding has an owner and a timeline.

Define Your SLAs

Establish and document remediation timelines. These are the industry norms:

Document these in a policy (even a Google Doc counts). Auditors and enterprise customers will ask for it.

By day 60, you have a real program. Phase 3 is about deepening coverage and making the program measurable — both for internal improvement and external stakeholder confidence.

Expand Scanning Coverage

Your initial DAST scan probably covered your main web application. Now expand:

• API endpoints — authenticated API scanning requires configuration effort but surfaces a different class of vulnerabilities than unauthenticated crawling
• Authentication flows — session management, token handling, OAuth/OIDC configuration issues are rarely caught by default scan profiles
• Admin interfaces — internal tools and admin panels often have weaker security posture than customer-facing surfaces
• Infrastructure — cloud configuration scanning (if not already in place) catches IAM misconfigurations, open S3 buckets, exposed databases

Developer Security Training

AppSec at scale means shifting left — catching issues before they reach production. This requires developers who know what to look for.

You don't need a year-long training program. Start with a one-hour internal session on the OWASP Top 10 specific to your stack. Walk through a real finding from your scan results (anonymized or with dev's permission). Make it concrete, not theoretical.

Then add security to your code review checklist. Three items is enough to start:

• Are all user inputs validated and sanitized?
• Are queries parameterized (no string concatenation into SQL)?
• Are authentication and authorization checks present on every endpoint that handles user data?

Build Your Metrics Dashboard

To demonstrate program value and track improvement, measure:

Start reporting these monthly to engineering leadership. Numbers create accountability in both directions — when they improve, it's a win worth celebrating.

Plan Your First Penetration Test

Automated scanning covers a lot, but it doesn't replace human judgment for complex business logic flaws, chained vulnerabilities, or creative attack paths. Plan an external penetration test for month 4 or 5 — once your automated scanning has cleared most of the low-hanging fruit.

Sending a clean-ish application to a pentester is more productive than sending one with 50 known unpatched vulnerabilities. They'll find more interesting things, and you'll get better ROI on the engagement.

What Most AppSec Programs Get Wrong

Starting with policy instead of practice

Writing a 40-page security policy before running a single scan is backwards. Policy follows practice — document what you're actually doing, not what you aspire to do. Real programs run scans first, then write the policy that reflects the process.

Treating security as a gate, not a partner

AppSec teams that only say "no" eventually get routed around. The most effective approach is becoming a resource — helping developers understand findings, providing fix guidance, and making it easy to do the secure thing.

Chasing 100% coverage immediately

You will not scan everything perfectly in the first 90 days. Pick your highest-risk surfaces and scan those well. A thorough scan of your five most critical applications beats a superficial scan of 50 services.

Ignoring developer context

Automated scanners produce findings without context. A finding that's Critical in CVSS might be Low risk in your specific deployment (e.g., a vulnerability in a feature no one uses, behind three authentication layers). Context from developers is essential for accurate risk prioritization.

Where You Should Be at Day 90

By the end of 90 days, a well-executed program should have:

• Complete asset inventory of all public-facing applications and APIs
• Automated DAST scanning running weekly against staging/production
• SCA integrated into CI/CD pipelines
• A documented triage process with clear SLAs
• At least 10–20 high-severity findings remediated and verified
• Basic developer security training completed
• A metrics baseline to track improvement over the next 90 days
• A penetration test scoped and scheduled

This is not a complete AppSec program — that takes years to mature. But it's a real foundation. Every element above is something you can demonstrate to an auditor, a prospective customer, or a board asking "what are we doing about security?"

The goal at 90 days isn't perfection. It's a program that runs without your constant intervention, produces actionable findings, and gets better every sprint.