Skip to main content
Table of Contents

Security & Compliance

This guide is for Security and Compliance leaders who need line-of-sight from security policies to daily engineering behavior. It focuses on using Metrics → Quality , Metrics → Delivery , and gitStre…

heather.hazell
Updated by heather.hazell

This guide is for Security and Compliance leaders who need line-of-sight from security policies to daily engineering behavior. It focuses on using Metrics → Quality, Metrics → Delivery, and gitStream to design low-noise standards that reduce risk without stalling development.

TL;DR – Security & Compliance:

  • Use Metrics → Quality and related reliability signals to identify risk patterns.
  • Use Metrics → Delivery to understand how PR and deployment behavior influence that risk.
  • Use gitStream to encode security standards as low-noise PR policies (review rules, sensitive paths, etc.).
  • Partner with DevEx/Platform and SRE to ensure security guardrails support, not block, delivery.

Start here in 15 minutes

  1. Choose one security-critical area (service, repo, or directory).
  2. In Metrics → Quality, review the last quarter for that area and note any periods with more issues or incidents.
  3. Switch to Metrics → Delivery for the same team or service and check:
    • Whether those periods lined up with large PRs or rushed reviews.
  4. Write down one concrete behavior you want to improve (e.g., “no huge PRs in auth,” “extra review on certain paths”).
  5. If gitStream is enabled, open the gitStream Hub and identify where that behavior could be turned into a simple rule.
  6. Bring this as a single, focused ask to your DevEx / Platform partner.

Who this guide is for

  • Security leads responsible for secure SDLC practices.
  • Compliance owners who must show evidence of controls (e.g., for audits).
  • Leaders partnering with DevEx, SRE, and QA/Release on standards.

What you likely care about

  • Are risky changes being caught early enough in the lifecycle?
  • Do high-risk areas (services, repos, directories) get the right level of scrutiny?
  • Can you demonstrate that security standards are actually followed, not just written down?
  • Can guardrails scale automatically instead of relying on manual review for everything?

Before you begin

  • Key repos and teams are connected in LinearB.
  • You know which services or directories are security-critical (e.g., auth, payments).
  • You have access to Metrics → Delivery and Metrics → Quality for relevant teams.
  • gitStream is enabled or can be enabled on critical repos (if your org uses it).

Step 1: Use Quality metrics to understand risk patterns

Goal: See where quality issues cluster so you know where to harden controls.

Where: Metrics → Quality

  • Focus on services / teams tied to sensitive data or critical flows.
  • Review:
    • Signals that show defect or incident patterns over time.
    • Changes in quality around release windows or large feature pushes.
  • Tag 1–2 services or areas where quality risk looks consistently higher than peers.

Step 2: Connect risk to delivery behavior

Goal: Link security/quality issues to how code is actually shipped.

Where: Metrics → Delivery

  • For each high-risk service/area, look at:
    • PR size distribution (many big changes vs. smaller, safer ones).
    • Review patterns – are PRs getting enough review time?
    • Stage-level trends (e.g., frequent rushed reviews before deploy).
  • Note patterns like:
    • “Large, multi-feature PRs going into auth service with minimal review.”
    • “Critical services see more rushed merges near release deadlines.”

Step 3: Define security standards you can encode

Goal: Turn policies into precise, testable rules.

  • Pick a short list of behaviors for critical paths, such as:
    • Minimum review depth or required reviewers for sensitive directories.
    • Stricter limits on PR size in high-risk services.
    • Extra checks for PRs touching authentication, authorization, or data-access code.
  • Partner with DevEx/SRE to ensure these standards are:
    • Clear (easy to understand).
    • Low-noise (few false positives).
    • Scoped to high-risk areas first.

Step 4: Use gitStream to enforce low-noise security guardrails

Goal: Encode standards as automation instead of tribal knowledge.

Where: gitStream Hub (if enabled)

  • Start with a single critical repo or directory.
  • Implement rules such as:
    • Route PRs touching sensitive directories to specific reviewers.
    • Flag PRs that exceed a safe size threshold in those areas.
    • Require certain checks (tests, linting, scanning) before merge.
  • Roll out gradually and watch Delivery metrics to confirm you’re not creating bottlenecks.
Principle: Favor targeted guardrails in high-risk areas over blanket rules everywhere. This keeps signal high and pushback low.

Recommended operating rhythm

Monthly

  • Review Quality and Delivery patterns for 1–2 critical services.
  • Identify one security behavior to improve (e.g., review depth on auth changes).
  • Partner with DevEx/SRE to add or adjust a gitStream rule for that behavior.

Quarterly

  • Summarize:
    • Where security guardrails have been applied.
    • Any change in defect/incident patterns for those areas.
  • Use this summary as part of audit evidence and roadmap discussions.

Recommended next articles

How did we do?

SRE, Infra, Reliability

Tech Lead & Developer

Contact