# How We Scaled Security Reviews Without Slowing Down Engineering At Postman, we ship fast. Velocity is part of our culture. But as we scaled, one question kept resurfacing: **How do we maintain strong security assurance without becoming the bottleneck?** We’re sharing the evolution of our Security Review Process (SRP). What didn’t work, what we changed, and how we built SRP v2, a risk-based, automation-first security model embedded directly into our [SDLC](https://www.postman.com/security/). ## **Why Our Previous Model Stopped Scaling** Our previous security review process fully revolved around a VAPT (Vulnerability Assessment & Penetration Testing) Jira ticket and the corresponding security test plan. Here’s how it worked: - When a service release moved to staging environment (‘develop’ pre-production branch code merge), a VAPT ticket was automatically created - The primary AppSec contact for that service was notified - AppSec would manually review the entire release before GA On paper, it sounds reasonable. In practice, it created several challenges: 1. **Security Notification Was Tied Too Late to VAPT Ticket Creation** Our process relied almost entirely on VAPT ticket generation as the trigger for notifying AppSec. In many cases, AppSec was not formally looped in during the design or planning phase; hence, AppSec became aware of some changes only when a VAPT ticket was created after the service moved to the staging environment. By that point, the release was already close to GA. This led to: - Late architectural and implementation questions on certain releases - Compressed timelines for meaningful manual security review - Crunch mode for the AppSec team - Major security findings surfacing as release blockers, impacting delivery schedules 2. **Design-Phase Review Process Was Informal** For major features, AppSec was often consulted during design. But there was: - No formal process - No central tracking - No consistent documentation - No measurable assurance As we scaled, this informality became friction. 3. **Lack of Risk Differentiation** The model treated all releases similarly. A low-risk configuration change and a high-impact auth redesign would both trigger similar review mechanics. That doesn’t scale. And at Postman, scale matters. ## **The Realization: Security Must Scale With Product** We had to confront a fundamental truth: Security cannot just sit as a manual gate in front of a fast-moving train. If engineering scales through automation, frameworks, and reusable systems, AppSec must do the same. The goal wasn’t to review less. The goal was to review smarter. About a year ago, we started acting on this. We piloted an early version of this model with a subset of services and teams, working closely with engineers, engineering managers, and product leaders. This helped us identify gaps, refine the approach, and validate what worked in practice. That led to Security Review Process v2 (SRP v2). SRP v2 wasn’t designed in theory, it was built on operational evidence. Instead of arbitrarily cutting manual reviews, we used data to design risk-based pathways. We started by adding structured, required fields for the security engineers to record before a VAPT Jira ticket can be closed. The following custom fields were added to the VAPT jira ticket: - Was manual security review required? (Yes/No) - Manual review effort (In hours) - Release type reviewed (Major/Minor) ![](https://blog.postman.com/wp-content/uploads/2026/04/13-anurag.png) This gave us something we previously lacked: consistent, field-level operational data directly from the security engineers performing the reviews. With this, and other data points, we now measure: - How often releases for a given service or team truly require manual review - The distribution of major vs. minor releases - Average manual effort spent per release - Trends in early vs. late AppSec involvement - Where manual review effort can possibly be reduced ## **SRP v2: A Risk-Based Security Review Model** SRP v2 is a calibrated system designed to learn, adjust, and evolve as our product and organization grow. ![](https://blog.postman.com/wp-content/uploads/2026/04/11anurag.png)### **How We Re-Architected the Security Review Process** 1. **New AppSec Review (ASR) Jira Ticket** Every major release now has a dedicated ASR Jira ticket; acting as the central source of truth for the release’s security lifecycle. ASRs are auto created as soon as the product release Jira ticket is moved to “In Progress” state. Tracking: - Product release ticket - VAPT tickets (per service release) - Dependent release ASR tickets - Triage questionnaire for initial triage and planning - Master security test plan - Security review status and final sign-off state Earlier security sign-offs lived mostly in scattered VAPT tickets, now every significant release has a canonical security hub. VAPTs are linked children, not isolated artifacts. 2. **Mandatory ASR-Level Security Triage Questionnaire** Every ASR includes a security triage questionnaire. Product Managers/Release Owners are directly responsible for filling this out when the ASR is created. These answers drive: - Initial risk classification - AppSec prioritization - Review depth decisions The goal is simple: give security structured visibility during design and iteration phase. 3. **Mandatory PR-Level Security Triage Questionnaire** In addition to the ASR-level security questionnaire (which captures release intent and high-level risk context), we introduced a second layer of triage directly inside the pull request workflow. Before commits can be merged into the develop branch, the code author must answer a mandatory set of yes/no security questions. Unlike the ASR questionnaire, PR-level triage focuses on concrete engineering changes. These questions are tightly scoped to implementation details because developers understand their changes best, and the context is fresh at merge time. Over the past year, we’ve iterated on and refined this question set based on real-world usage and review outcomes. As a result, we’ve found it to be highly effective in surfacing meaningful signals early. For every service release, our system aggregates all PR-level yes/no responses, and then a consolidated view is automatically posted to the VAPT Jira ticket tracking that release. If any PR answers “Yes” to a question, the corresponding VAPT-level field is marked “Yes.” 4. **Security Masterplan per Major Release** Every major release now requires a central security masterplan document. This document will: - Link to the ASR Jira ticket - List all VAPT Jira tickets for that release - Track required security controls discussed during design reviews - List security test coverage, and findings from tooling and manual penetration test Earlier security notes were scattered across service-level VAPT tickets, now we have one canonical security tracker per major release. The entire release’s security posture is documented in one place. 5. **Risk-Adaptive Review Routing** One of the most important changes in SRP v2 is that not every service, and not every release, follows the same review path. In the previous model, manual review was the default. In SRP v2, review depth is intentionally aligned to service criticality and the actual sensitivity of the changes being shipped. For Low and Medium severity services: if all triage answers across PRs indicate no security-sensitive changes, the VAPT Jira ticket is automatically closed. That closure represents security sign-off. There is no waiting period, no manual gate, and no unnecessary friction. If any triage response signals risk, the release moves into a normal manual security review flow. Auto-closure does not mean reduced security coverage. These releases still pass through our baseline guardrails, including secure SDLC requirements, automated SAST and SCA (dependency scanning), secret detection, infrastructure policy enforcement, cloud security posture management, logging standards, and centralized detection and response monitoring. Many services are also backed by Postman collection–based regression and security test suites that validate critical flows on every release. In addition, releases remain covered by broader assurance mechanisms such as periodic internal reviews and our [bug bounty program](https://www.postman.com/security/vulnerability-reporting/). Automation replaces synchronous review, it does not replace security. For High and Critical severity services: manual review is always required for now, regardless of how triage questions are answered. The potential blast radius is simply too large to rely solely on current automation. These services demand deliberate human scrutiny, and VAPT Jira tickets are closed only after explicit AppSec sign-off. 6. **Continuous Validation & Improvement** Automation without oversight is risky; hence, we introduced a safety net where all the auto-closed releases are audited monthly by AppSec to validate that triage decisions were accurate and that risk signals remain trustworthy. During these reviews, we examine whether any releases should have received deeper review, whether triage responses accurately reflected the underlying changes, and whether a service’s criticality classification still makes sense given its current evolution. These audits allow us to refine the questionnaire, recalibrate criticality levels, and continuously improve the safety of our automation. If patterns shift, the model adapts. ## **What SRP v2 Has Enabled for Us** ![](https://blog.postman.com/wp-content/uploads/2026/04/12-anurag-1024x603.png)- **25% of Releases Auto-Unblocked:** 1 in 4 service releases now move from staging to production with no real-time manual security sign-off - **Wait Times Cut**: Removed 2 business days of average per-VAPT closure time for qualifying releases - **Developer Productivity Gains:** 22 developer and security work-hours per quarter saved in reduced context switching - **Security Capacity Reclaimed:** 3 full business weeks of AppSec team capacity freed up every half-year ## **What’s Next: Organically Scaling Security With a Living Risk Matrix** We’re moving toward a system where risk decisions and security insights continuously improve over time. That means building a data-driven risk matrix to better decide where human effort truly belongs, while also integrating AI to bring faster, more contextual intelligence into the security review workflow. Think of this as a continuous conversation with the system, and not a one-time design. As our product grows in complexity, our framework will adapt, and recalibrate based on real signals, not assumptions. ### **A Structured, Data-Backed Risk Model** We’re building a model that categorizes releases into three actionable risk buckets based on a composite risk score. That score blends: - **Service Criticality:** The potential blast radius if a service is compromised - **Historical Vulnerability Patterns:** Past hygiene and recurring issues - **Change Sensitivity Trends:** Signals from aggregated triage data (e.g., auth changes, new APIs, PII handling, infra changes) This structure balances intrinsic risk (what the service is) with operational signals (how it’s evolving). **Actionable Risk Zones:** The risk score will ultimately place services and releases into three clear buckets tied to a different level of security involvement. - **Autonomous Release Zone (Low Risk):** Low criticality, clean history, and low recent sensitivity. These rely primarily on automation and periodic assurance; no routine blocking security reviews - **Assured Oversight Zone (Medium Risk):** Moderate criticality or elevated change sensitivity. Limited to scheduled reviews, focused scope bug bounty coverage, and targeted pentesting; not necessarily per-release gates - **Critical Review Zone (High Risk):** High-impact services or compounded risk signals. Mandatory manual security reviews for each such release with deeper scrutiny ### **AI Augmented Security** Parallely, we are integrating intelligence closer to the development workflow, from surfacing vulnerabilities directly in pull requests to experimenting with agentic approaches that go beyond traditional LLM-based scanning. We’re also exploring autonomous validation at runtime to verify findings more realistically, along with an internal RAG-based assistant to help our security team reason faster using historical context and prior decisions. ## **Final Thoughts** [We care deeply about safeguarding our users and our platform,](https://blog.postman.com/postman-free-is-secure-by-design/) while making sure our engineering teams can move fast with confidence and trust in the system around them. Being product-first doesn’t mean relaxing standards. It means designing security mechanisms that understand business context, developer workflows, and real-world risk. It means building frameworks that scale naturally, adapt to change, and stay grounded in data. We’ll keep refining this model as our product and threat landscape evolve. Because in the end, strong security is about building trust at the speed of innovation.