Product Security Scorecards: Coupling Security Issues with Preventative Controls to Drive Security Maturity

Postman’s commitment to Product Security begins with our approach to Application Security. Every engineering team in Postman has an assigned Security Engineer who reviews new features and services in development to ensure that security is baked into the product. This security review process gives us a solid foundation to build on, but as we scaled from a small API client into the feature-rich API platform we are today, we ran head-first into the most traditional of security problems: teams were drowning in security findings.

Even with embedded Security Engineers, keeping up with and triaging the findings from all the tools was becoming overwhelming. Our response? Custom-built Product Security Scorecards.

What are Product Security Scorecards?

Postman’s Product Security Scorecards aggregate vulnerability findings, control health monitoring, and security-spawned requests and requirements into a single pane of glass, which engineers and engineering management at all levels can monitor.

The first step was to leverage the understanding of the product from our embedded Security Engineers to attribute all production/runtime services and artifacts back to their builds/pipelines, source repos, and owning teams. The second step was to use that same mapping to attribute all the outputs of the myriad security tools and processes deployed across the SDLC to the same teams. Finally, with all this in place we needed to make it consumable, actionable, and ensure that it properly incentivized the behavior we needed. So we honed in on what we saw as the most important Security Issues, and paired them with Preventative Controls designed to address them proactively. Teams could then see how investing a little time in enabling these controls would prevent issues from making it into production and reduce their remediation workload. It also enabled a positive feedback loop where teams could help us identify areas for improvement in self-service and automation, making it easier to stay on top of findings.

To illustrate how we operationalize this framework and how these positive feedback loops are driving outcomes in Postman, we’ve chosen one of the common classes of problems product security teams tackle: Third-Party Dependency Vulnerabilities

Third-Party Dependency Vulnerabilities

New vulnerabilities in third-party dependencies are found regularly. As a company scales and tech debt accumulates, staying on top of them becomes increasingly challenging, and buy-in from dev teams is required in order to solve the problem at scale.

Security Issues

When we initially rolled out Scorecards, we did as most companies do with Third-Party Dependency Vulnerability programs, and chose to begin by highlighting just the direct dependencies containing Critical or High vulnerabilities for immediate attention. By scoping the initial ask in this way, our Security Engineers were able to go to their respective teams and get the needed buy-in to do burn-down campaigns across the company. As these took off, we were delighted to start getting messages from folks who were asking why we weren’t bugging them about similarly severe transitive dependency issues (these being dependencies of your own dependencies).

This collaborative back-and-forth has enabled us to ask more of the company and use the teams that have reached a given level of maturity with their patching as example cases to drive further security improvements.

Preventative Controls

Although holding teams to stricter standards over time is industry-standard practice, Scorecards shine by pairing those Issues with Preventative Controls that help Engineering stay on top of them and accelerate our ability to raise security standards. In the case of Third-Party Dependency Vulnerabilities, we define five levels of maturity for the program:

• Repo Scanning: Turned on by default, this is the source of the relevant Security Issues we highlight.
• PR (Pull Request) Scanning: Also enabled by default, it was our first step to “shift left.” We used PR scans to give teams the chance to fix issues before code reached production and tune our checks. Running scans in “warn” mode let us identify false positives, refine rule thresholds, and improve the developer experience so the checks would be actionable when enforced.
• PR Blocking: This is where the Scorecards model starts to pay dividends. After iterating on rules in scanning mode and trialing blocking with some bellwether teams, we rolled PR Blocking out company-wide. Blocking actions can be disruptive to developer workflows, but pairing the controls with the specific Security Issues they were designed to prevent made it much easier to secure buy-in from Engineering management and ICs.

A key part of what makes Scorecards work is the way it pushes us iterate on our controls, and build systems Engineering can onboard into to help them fix things easier/earlier/faster, so we’re excited to give you a peek into two additional controls we’re building we think Scorecards are uniquely suited to helping drive adoption for:

• Client-Side Scanning: Client-side checks let teams see problems as they develop, but they are intrusive and can be easily bypassed, so developer buy-in is critical. Teams that want to push their fixes as early in the development cycle as possible will soon be able to include security-defined client-side git hooks to let them identify vulnerable dependencies in a pre-commit hook.
• Client-Side Blocking: For teams that really want to take their security to the max, we will also make a blocking pre-push check available.

These types of checks are often too disruptive for many companies to attempt to enforce, and so if offered at all are typically offered as an optional opt-in. But without a centralized and integrated view like Scorecards to drive buy-in, they tend to fail to achieve broad adoption and fail to drive outcomes.

Although this is just one example, we hope it illustrates how the framework can scale to other common Security Issues (e.g., SAST scans, container vulnerabilities) and to bespoke controls like adopting hardened base images to speed remediation.

Security Asks

Not everything the security organization asks Product to work on fits neatly into the Security Issues/Preventative Controls maturity model. For those items we use the “Security Asks” section of Scorecards, a flexible feed that pulls Jira tickets from product projects and then attributes, categorizes, and tracks them so teams and leaders can act:

• security-improvement: A generic bucket for hardening tasks (improving logging, rolling out tagging enforcement, refining WAF rules, etc.). These are used to drive focused remediation work and continuous hardening across services.
• audit/certification readiness: When we’re preparing for an audit or certification, Security Asks collects all outstanding items across Product so leadership can see how close we are to readiness — without creating a separate reporting framework. This gives program owners a single place to prioritize and drive work.
• release blockers/review gaps: These are issues found during security reviews or scans of feature branches that would be unacceptable in a live product. Because features evolve rapidly during development, it’s often impractical to block every finding immediately. We therefore let teams continue internal development, but track those items as “release-blocker” tickets so they remain top of mind during release readiness reviews. This keeps them distinct from validated production Vulnerabilities (e.g., penetration test findings or bug-bounty reports), which are handled under a different remediation workflow.

While this isn’t an exhaustive list, we hope it illustrates how Scorecards act as a single pane of glass for outstanding security work: surfacing items, showing ownership, enabling triage, and letting leaders run company- or team-level remediation campaigns.

But who looks at this anyway?

In short: everyone.

Scorecards leverage layered attribution that mirrors Engineering’s org structure so anyone, from an engineer who owns a single microservice to a Unit Head or the Head of Engineering, can view the health of their services. At-a-glance traffic-light scores (red, yellow, green) surface posture immediately, and trends data let teams track progress over time and help leaders identify high-performing teams and those that need more support.

Our Scorecards do more than provide visibility. The tight coupling of Security Issues with Preventative Controls surfaces not only the problems but the specific controls that can be enabled to prevent them. Tying this all together makes the impact of enabling controls visible in the trends charts, and create a feedback loop that incentivizes better engineering practices: managers can prioritize high-impact work, engineers see the concrete benefit of adopting controls, and Security can invest in self-service tooling that lowers the friction to comply. That coupling of attribution, action, and measurable outcomes turns security from an endless list of alerts into a roadmap for continuous improvement, making best practices as easy to adopt as possible.

We hope this overview shows the investments we’re making to secure Postman’s API Platform and gives you confidence that your data is safe with us, and we look forward to sharing more details about the controls we’ve built and the security journey Postman is on in future posts.