Opsera Forge

Security modernization

Every artifact that passes through the Forge pipeline is inspected by a dedicated Security Agent. Not a post-hoc scan: security analysis happens at generation time, before the artifact reaches you.

  • Belcorp
  • Senao Wireless
  • Elevance Health
  • Guardant Health
  • LTM
  • Revinci
  • 5Security checks
  • 4Pipeline stages inspected
  • 8ForgeScore dimensions

What the Security Agent actually checks

Five named checks run against every artifact as it is generated, plus a set of guards specific to how AI systems get attacked. All of it is visible before you approve a stage.

  • Auth coverage

    Is authentication defined for every user-facing endpoint? Gaps surface while the architecture is still a document, not after the endpoint ships.

  • Secrets handling

    No hardcoded credentials in specs or in generated code. Detected secrets are also redacted from connector-backed context before they are persisted or displayed.

  • Input validation

    Every user input carries a validation requirement, checked as a property of the specification rather than left for a code reviewer to notice.

  • Dependency risk

    Third-party libraries are flagged for known CVEs, and supply chain dependency risk is assessed while the architecture is being reviewed.

  • Compliance gaps

    Missing controls for the compliance requirements you declared. Requirements captured at intent are carried forward rather than rediscovered late.

  • Guards built for AI-generated systems

    Prompt injection patterns in specs, MCP tool definitions that could leak context to external endpoints, and scope creep beyond the approved specification boundary.

Where security shows up in the pipeline

Four stages are inspected as they generate. Each looks for something different, because a security problem in an intent document does not look like one in an architecture.

  1. 01

    At the intent stage

    Ambiguous or conflicting requirements that could lead to insecure designs, missing security requirements such as auth, data protection and audit logging, and compliance requirements that must be carried forward.

  2. 02

    At the PRD stage

    Features that require security controls are flagged for explicit inclusion in the architecture, alongside out-of-scope exclusions that might create security gaps and data classification requirements.

  3. 03

    At the architecture stage

    OWASP Top 10 mitigations present in the design, authentication and authorization flow completeness, secrets management patterns, supply chain dependency risks, and network segmentation with least-privilege service design.

  4. 04

    At the user stories stage

    Security stories explicitly included in epics, penetration testing tasks included, and dependency scanning tasks included, so the work is scheduled rather than assumed.

How security review works

Security analysis happens at generation time, artifact by artifact, and every finding is visible before you approve a stage.

01

Score the codebase

Eight weighted dimensions return a composite score and a maturity label. The radar shows where the system is weakest, and the highest-severity findings sit beside it with the file each one was found in.

02

Filter to security and compliance

One toggle filters to critical and high severity findings and to anything mapped to OWASP Top 10, CWE, GDPR Article 32, or SOC 2, drawn from every dimension at once rather than a single security tab.

03

Read the dimension

Trust Boundaries covers security boundaries between components and data flows. It returns a score, a written summary of how trust is actually enforced in your code, and the strengths worth keeping alongside the gaps.

04

Open a finding

Each finding carries severity, the file it was found in, a description of the failure mode, a suggested fix, an effort estimate, and its compliance references. Enough to decide without opening the codebase.

05

Decide what to fix

Findings are informational and do not block pipeline progression. The Roadmap tab ranks them as surgical strikes, each with an estimated score lift, so triage is a judgement your team makes with evidence rather than a gate the tool enforces.

06

Prove the improvement

Remediate, then use Quick Re-score or Run New Version and compare the two side by side. The composite and per-dimension deltas show whether the work moved the number it was meant to move.

From finding to work order

Every finding carries severity, the file it was found in, an effort estimate, and its compliance references. Here is one Trust Boundaries finding as it appears in the report.

ForgeScore findingHigh severity finding

Trust Boundaries42

Security boundaries between components and data flows. Foundation maturity: auth patterns exist and are well built, but enforcement is inconsistent across routes.

Trust Boundaries findingOWASP-A01

Service-role key used as silent fallback when anon key would suffice

One route falls back to the anon key when the service key is missing, while others default the opposite way. A misconfigured environment silently escalates or de-escalates privilege. Tagged OWASP-A01 and CWE-269, medium effort, high velocity impact, with a suggested fix attached.

Common challenges

Security review surfaces the decisions a project tends to defer. These are the ones worth resolving before you approve a stage rather than after.

  • Findings do not block progression

    By design, findings are informational. That keeps the decision with your team, but it also means someone has to own triage. Without that, an amber callout is just a callout.

  • Declared compliance drives the gap check

    The Compliance Gaps check looks for missing controls against the requirements you declared. If the requirement was never captured at intent, there is nothing to check against.

  • Prompt injection is a spec-level risk

    Forge detects patterns in specs that could enable user-controlled prompt manipulation. That is a class of problem most review checklists were never written to catch.

  • Tool definitions can leak context

    MCP tool definitions that could exfiltrate context to external endpoints are flagged. If you are connecting agents to internal systems, this is the exposure to understand first.

Frequently asked questions

Is this a vulnerability scanner?

No. A Security Agent inspects each artifact at generation time, before it is presented to you, and ForgeScore baselines the existing codebase. Both produce findings for your team to act on rather than a scan report at the end.

Does this cover the OWASP Top 10?

At the architecture stage the Security Agent checks that OWASP Top 10 mitigations are present in the design. ForgeScore findings also carry compliance references such as OWASP and CWE where they are mapped.

Do security findings block the pipeline?

No. Findings are informational and do not block progression. They appear inline as amber or red callouts, and your team decides whether to address them before proceeding.

What are the eight ForgeScore dimensions?

Trust Boundaries, Logic Narrative, Code Excellence, Data Weight, Cognitive Load, System Gravity, Semantic Clarity, and Future-Proofing. Each is weighted into the composite score, and Trust Boundaries carries the security boundary analysis.

How do I prove security improved?

Re-score after remediation using Quick Re-score or Run New Version, then use Compare Versions for a side-by-side against your earlier baseline. ForgeScore is an input to human decisions, not a substitute for security sign-off.

See your ForgeScore before you commit

Security review on Forge is not a stage you reach at the end. A Security Agent inspects intent, the PRD, the architecture, and the user stories as each one is generated, and ForgeScore baselines the codebase you started from.

Ship enterprise software at AI speed.

Every modernization path is spec-first and governed from Day 0.