Start with a small operating loop: identify the applications that could cause the most harm, review a bounded part of one or two of them, turn credible issues into owned work, and check whether fixes worked. Give the engineer a sponsor who can allocate development time and decide on unresolved risk. Record what was assessed and what was not. A scanner subscription, a policy document, or a backlog of alerts is not yet a program.
The starting point changes if there is an active incident, a known exploited vulnerability in an exposed component, or a contractual deadline. Handle that time-sensitive work through an urgent lane while keeping the ordinary loop small. NIST's Secure Software Development Framework (SSDF) 1.1 supplies a broad set of practices to integrate into a development lifecycle; it does not require a one-person team to launch every practice at once. OWASP SAMM likewise separates governance, design, implementation, verification, and operations so a team can choose a useful next improvement.
Define the unit of work before buying tools
An AppSec program reduces application risk through repeatable decisions. For a small team, its first output should be a short, defensible answer to four questions:
- Which applications and changes are in scope this month?
- Who decides whether a reported issue is real enough to assign?
- Who owns a fix or an explicit risk decision?
- What evidence would show that the issue was closed?
Name one accountable security lead and one engineering sponsor. The security lead owns the review method and evidence record. The sponsor protects engineering capacity, resolves disputed ownership, and accepts or escalates business tradeoffs under company policy. Product and service owners supply deployment facts and implement changes. A security champion may help a team use the process, but should not become an unpaid substitute for the security lead or a hidden risk approver. OWASP's Security Champions Guide explicitly calls for management support, a dedicated program captain, trust, and investment in champions.
Select activities against a business objective rather than a tool catalogue. OWASP SAMM's Strategy and Metrics practice asks a program to identify its drivers and measure whether its work is effective. For a new team, a defensible objective could be: “Within one quarter, every customer-data application has a named owner, and the two highest-impact applications have an assessed change or trust boundary with a recorded disposition.” That is a local target, not a claim that those applications are safe.
An illustrative first quarter
Illustrative company, not a customer result: Northstar Billing has 18 repositories, 45 engineers, one security engineer, and a Head of Engineering who can sponsor two hours of remediation planning each week. Its customer-facing billing API handles invoice PDFs and payment state. An internal design-system repository builds UI components. A legacy export worker can read billing records, but its owner is uncertain.
Northstar cannot make “scan all 18 repositories” a useful first outcome. The security engineer builds a one-page application inventory, asks which deployed services can read or change customer billing data, and maps those services to repositories and owners. The billing API and export worker become the first assessment candidates. The design system stays inventoried, with a reason for later review. A shared authorization library used by both candidates is included as a dependency of their assessment even though it has its own repository.
The engineer chooses one initial question: Can a user or internal job retrieve an invoice from another customer account? The review traces the chosen actor, route or job entry, ownership check, and result at pinned revisions. It also records missing deployment facts. The first pass could find a credible flaw, defeat a scanner alert with a real downstream check, or remain inconclusive. Each outcome is useful when its evidence and next owner are recorded. A line citation alone does not prove a harmful path, and source review is not an executed penetration test.
Northstar's first quarter can be organized as follows. The timeboxes are an illustrative allocation; adapt them to actual capacity and incidents.
| Period | Security lead's output | Sponsor or owner action | Evidence that the step happened |
|---|---|---|---|
| Weeks 1–2 | Application-to-repository map, owners, data and exposure assumptions, first two choices | Confirm service owners and reserve review and fix time | Dated inventory with unknowns and decision reason |
| Weeks 3–4 | Bounded assessment of one path in billing API; candidate and counterevidence notes | Service owner supplies route, deployment and control facts | Pinned revision, selected scope, reviewed paths, exclusions |
| Weeks 5–8 | Reviewed dispositions and short developer handoffs | Sponsor reserves a qualified peer reviewer outside the original review and plans approved issues; unresolved claims retain evidence owners | Independent review record, approved tickets and investigation tasks, not an alert dump |
| Weeks 9–12 | Reassessment of merged fixes; next application choice | Service owner confirms deployment and new revision | Fixed, still present, or inconclusive result with positive evidence |
The sequence makes two constraints visible. First, the security engineer cannot both review an unlimited inflow and validate every fix. Second, a high-impact application may span several repositories. Selecting a repository without its shared authorization or deployment configuration could create a reassuring but incomplete result. Use the repository selection guide for the detailed ranking method.
Keep a one-page program charter
A charter prevents the first urgent ticket or tool demo from silently changing the program's scope. Here is a filled artifact for Northstar. Its names, numbers, and dates are illustrative.
- Objective: Make customer-data access failures visible and fixable in the billing workflow during this quarter.
- Sponsor / security owner: Head of Engineering / security engineer.
- Initial applications: Billing API and export worker. Include the shared authorization library and deployment routes needed to evaluate their access paths.
- Selection reason: Both can reach invoice data; billing API is customer-facing; export worker ownership and job authority are uncertain.
- Review capacity: Four hours of security investigation, two hours of engineering decision time, and one protected hour from a qualified application-security peer outside the original review each week, reassessed after four weeks.
- Review depth: Corroborate scanner claims against source and relevant controls. Reserve the peer for consequential, disputed or unfamiliar conclusions and material fix closure. Routine supported repairs use normal engineering review. Missing peer availability does not prevent a proportionate repair or containment; record what remains unconfirmed.
- Evidence record: Revision, deployment assumption, reviewed scope, counterevidence, disposition, owner, business impact, practical prerequisites, and verification result.
- Exceptions: Sponsor names a risk owner, reason, interim control, review date, and expiry; the security lead retains the technical record.
- Quarter check: Are the selected boundaries reviewed, are verified issues assigned, and do merged fixes have positive reassessment evidence? Record unreviewed components and capacity gaps.
This is deliberately a decision document, not a declaration of “secure software.” It can be linked from a concise application security policy template. If it cannot fit on one page because every project needs a different exception, the team probably needs a more explicit application inventory or ownership map.
Watch the charter survive three difficult weeks
The charter becomes useful when someone asks it to do more than the calendar allows. Continue Northstar's constructed quarter with three decisions. The supplied review outcomes illustrate the operating model; no assessment was executed for this article.
Week 4: the second application is still an orphan. The billing route map arrives, but neither Platform nor Finance accepts responsibility for the export worker. The security engineer could spend the next four-hour block searching its scheduler. Instead, the sponsor names Finance as the accountable service owner and Platform as the provider of runtime facts. Finance must return the schedule, credential scope and current release by Friday. That request does not make the worker assessed. The next four-hour security block remains on the billing path, where the controlling evidence is available.
The resulting inventory entry is useful even without a vulnerability verdict:
Application: legacy invoice export
Accountable owner: Finance engineering manager, acknowledged
Runtime evidence provider: Platform on-call
Known: source can read billing records; shared authorization dependency identified
Missing: live schedule, worker identity, effective release
Assessment: not started; initial applicability discovery blocked
Next decision: Friday; sponsor intervenes if artifacts are still missing
Week 6: the independent peer is unavailable. The original investigator traces an invoice read without an account predicate. The route is deployed, but the final peer check has not happened. A manager asks to count the issue as confirmed for a customer update. The lead declines that status change and writes: “One high-consequence candidate awaits independent review; the selected route is temporarily restricted under the service owner's authority.” The restriction is a response to uncertainty, not evidence that the claim is true. The record names its business cost: authorized users need the staffed invoice-delivery fallback until the route can be restored. If that fallback is unavailable, the sponsor must choose another response rather than invent one.
The service owner can prepare the account-bound repair during that week using normal code review. The following protected peer hour checks the original evidence, counterevidence and proposed correction; assume it supports the claim. The lead spends part of the four-hour allocation preparing this packet instead of starting another investigation. Independent challenge protects the consequential verdict without forcing useful repair work to wait.
Week 8: decision time has been mistaken for fix capacity. The sponsor's two hours a week fund planning, not a developer's repair. The owner estimates one developer-day for the scoped change, plus later verification. “We already allocated security time” is not an answer. The sponsor moves one day of billing feature work and names its owner. In the repair week, the security engineer's four hours are explicitly divided into one hour of intake, two hours of reassessment preparation and one hour for evidence follow-up. The independent peer retains the separate one-hour review slot. New discovery pauses; the worker assessment does not secretly continue off-calendar.
End the quarter with a defensible operating decision
Suppose the new billing revision is positively reassessed for the selected invoice path and its release is mapped. The quarter-end note should read like this:
| Commitment | Outcome in this exercise | What happens next |
|---|---|---|
| Billing invoice boundary | Selected path reviewed; one approved issue repaired and positively reassessed | Keep the evidence and add the invariant to relevant change reviews |
| Export worker | Owner and runtime facts obtained; security assessment deferred to fund billing closure | First bounded question next quarter: which account authority reaches job execution? |
| Portfolio visibility | 18 repositories inventoried; application map still needs reconciliation with deployment inventory | Sponsor assigns inventory reconciliation; no “18 repositories secure” claim |
| Sustainable review | One missed peer slot delayed a verdict; one developer-day required an explicit feature tradeoff | Retain backup peer capacity and negotiate actual repair allocation before expanding intake |
That note exposes a useful failure: the program can discover issues faster than its current review and delivery agreements can close them. Buying broader scanning would not remove this demonstrated bottleneck. The next capacity request is a backup qualified reviewer and an agreed repair allocation; tooling can be evaluated against a separate, evidenced need.
Keep incoming reports in a common tracking view, preserving their original source and revision. Track evidence status separately from work progress, using the team's existing tracker. Retain rejected claims and earlier decisions without requiring a new tool or a particular set of column names. The finding-triage guide supplies the detailed claim method; the cadence guide supplies the recurring calendar. The one-engineer program's job is to make those decisions possible without pretending that one person supplies every missing role.
Know when the plan must change
Expand the program when the first loop works: the evidence packet is readable, owners can challenge it, fixes are reassessed, and the security lead can describe uncovered scope. Add another application, a focused design review for a new trust boundary, or a champion with protected time. Do not add all three simply to increase activity.
If an urgent issue arises, use incident or exposure response with the right service owner. Do not wait for the weekly meeting. If the security engineer cannot access a deployment map or there is no authority to reserve fix time, escalate that organizational gap to the sponsor. If external legal or contractual obligations apply, have the appropriate owner and counsel interpret them; this general program does not establish compliance.
The first practical step today is to list five applications, their owners, the customer or business effect of compromise, and the repositories and shared controls they depend on. Pick one review boundary and book the first decision meeting. Then use the repository-selection method to justify what comes first and what remains outside the first assessment.