How Do You Set Up an Application Security Program?
Key takeaways
- A security development lifecycle only works if the requirements stage writes down what must not be possible, such as one customer reading another customer's data, because that is testable later.
- Automate the checks that machines are good at, including SAST, dependency scanning and secret scanning, and reserve human review for authorisation and business logic.
- A gate that blocks the release only works if someone owns it, so name a security owner in engineering and a named approver for the sensitive paths.
- Developer training tied to real findings in your own code works better than generic awareness sessions, and a 30-minute session a quarter with real examples beats an annual course nobody remembers.
- Measure the mean time to fix a high-severity finding and the number of high-severity findings that reached production, and report both to the leadership every month.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
What should a security program contain in its first quarter?
Four concrete items, and nothing more. First, a one-page security standard that says what the product must not do, written as testable statements, such as every request is authenticated, every record access is authorised against the owner, no personal data is logged, and no production credential is in the repository. Second, two automated pipeline gates that fail the build, one static analysis scan and one secret scan, tuned so they produce few false positives, because a noisy gate gets switched off. Third, a rule that changes touching authentication, authorisation, cryptography, payments or personal data need a second reviewer, and a named person who can approve it. Fourth, a baseline external assessment of the current product.
How do I make developers care without becoming a blocker?
Treat the developer as a partner, and the finding as a teaching moment. Put the standard where the developer already works, in the pull request, so a finding appears in the diff rather than in a separate report that nobody opens. Fix the class of defect once, in the shared library or the framework helper, rather than asking every team to remember the rule. Show the cost of the delay, so the developer sees that a two-hour fix now avoids a release-night incident, because engineers respond to consequences more reliably than to policy. And make it easy to comply, since a gate a developer can fix in ten minutes is one they keep.
How do I know the program is working, and what do I report?
Four numbers, reported monthly, with no commentary. The number of high-severity findings open on the product, and whether it is falling. The mean time to fix a high-severity finding, from detection to merge. The number of high-severity findings that reached production, which is the honest measure of the gates. And the percentage of pull requests that received a security review, since a low number means the process is being skipped even when nothing bad has happened yet. Add the compliance overlay for an Indian company: the CERT-In incident log with its 180-day retention, the DPDP Act data inventory, the processor agreements and the incident response plan with a rehearsed call tree.
| Layer | What it contains | When it starts |
|---|---|---|
| Security standard | Testable statements of what the product must not allow | Month one |
| Automated gates | SAST, dependency scanning and secret scanning in the pipeline | Month one |
| Manual review rule | Second reviewer for auth, crypto, payments and personal data | Month one |
| Ownership | A named security owner in engineering and an escalation route | Month one |
| Baseline assessment | Independent assessment of the current product | Quarter one |
| Training | Short sessions using real findings from your own code | Ongoing, quarterly |
| Metrics and reporting | Open findings, time to fix, escapes and review coverage | Monthly |
| Response readiness | Incident plan, log retention, notification path | Before launch |
What are the frequently asked questions?
Get a straight answer on this
Send us your repository and CI configuration, and we will return a gap analysis of your application security program with a costed 90-day plan.
Send us the details See pricing