# Security Decision Frameworks and Tool Trade-Offs

> **Intro:** Senior engineers are repeatedly asked to choose between tools that all appear reasonable: OPA or Kyverno, WAF or API policy, Vault or cloud-native secret managers, signed images or admission controls, vendor platform or in-house workflow. This page is about making those choices deliberately.

## How to compare controls without getting trapped by product categories

Use five questions first:

1. **What exact risk are we reducing?**
2. **Where in the lifecycle does the control act?**
3. **How much platform ownership does it require?**
4. **What telemetry does it create or hide?**
5. **What failure mode appears when the control is bypassed or ignored?**

If a team cannot answer those questions, the choice is probably being driven by branding or familiarity, not by engineering fit.

## Example 1: WAF vs gateway policy vs application control

| Option              | Best at                                                    | Weak at                     | Use when                                                                         |
| ------------------- | ---------------------------------------------------------- | --------------------------- | -------------------------------------------------------------------------------- |
| WAF                 | broad web attack filtering, bot pressure, virtual patching | fine-grained workflow rules | you need quick perimeter coverage and protection for many internet-facing assets |
| API gateway policy  | auth, routing, schema, quotas, token validation            | business-state checks       | you need consistent edge enforcement for APIs                                    |
| application control | object ownership, workflow state, domain constraints       | broad shared enforcement    | the rule depends on tenant, entitlement, state, or user intent                   |

**Pattern:** use WAF for broad hygiene, gateway for shared technical policy, and application logic for business truth.

## Example 2: OPA / Gatekeeper vs Kyverno

| Question                   | OPA / Gatekeeper bias                                            | Kyverno bias                                                             |
| -------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------ |
| team comfort               | strong for policy engineers who think in constraints and Rego    | strong for Kubernetes teams who prefer YAML-native policies              |
| mutation needs             | possible, but often less ergonomic                               | very natural for mutation and policy authoring in Kubernetes workflows   |
| cross-domain logic         | better when policy thinking extends beyond Kubernetes admissions | great when the primary problem is Kubernetes policy at the cluster layer |
| readability for developers | can be harder for non-specialists                                | often easier for platform users to review                                |

**Rule:** choose the tool your platform team can actually maintain. The right policy engine with no authoring discipline is worse than the “second-best” one with clear ownership and review flow.

## Example 3: Vault vs cloud-native secret manager

Choose Vault when:

* you need a stronger cross-cloud abstraction;
* you need dynamic secrets across multiple systems;
* you can support HA, auth backends, rotation workflows, and operational ownership.

Choose cloud-native secret managers when:

* most workloads stay within one cloud;
* identity federation is already strong;
* platform simplicity matters more than a universal abstraction layer.

## Example 4: signed artifacts vs runtime admission vs runtime anomaly detection

These are not substitutes.

* **Signing** answers: *did the artifact come from an approved source?*
* **Admission control** answers: *should this workload be allowed to run here?*
* **Runtime detection** answers: *what is this workload doing now?*

A common failure mode is funding signing and assuming that runtime risk is therefore solved.

## A practical choice model

Score each candidate control from 1 to 5 across:

* blast-radius reduction;
* implementation effort;
* maintenance burden;
* developer comprehensibility;
* telemetry usefulness;
* rollback complexity;
* coverage overlap with existing controls.

Then add one written answer to this question:

> **If this control is bypassed, how will we know and what remains true?**

That answer usually reveals whether the control is foundational or merely decorative.

## Decision traps to avoid

* choosing a control because a peer company uses it;
* treating “policy as code” as a sufficient architecture decision;
* choosing the most expressive tool instead of the most maintainable one;
* ignoring the detection and evidence value of the control;
* choosing a control that only security engineers can understand.

## Strong outputs from a senior reviewer

A good decision record should contain:

* the problem statement;
* the alternatives considered;
* explicit trade-offs;
* operational owner;
* telemetry impact;
* fallback plan;
* success criteria after 90 days.

## Suggested references

* OWASP ASVS — <https://owasp.org/www-project-application-security-verification-standard/>
* OWASP SAMM — <https://owasp.org/www-project-samm/>
* SLSA — <https://slsa.dev/>
* TUF overview — <https://theupdateframework.io/docs/overview/>

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/strategy-governance-and-leadership/index-1/security-decision-frameworks-and-tool-tradeoffs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.