The Real-⁠Time Evidence Layer

Fianu operates independently of your toolchain, continuously gathering evidence and enforcing policy in real time. It runs asynchronously and is always on.

Product animation to cover the most important flows

Every path to production,
no standardization required

  • No changes to your paths to production.

    Capturing compliance requires no standardization to your paths of production.

  • Compliance enforcement from commit to release.

    On every path of production you can enforce compliance gates.

  • Software can be governed without standardization.

    You can skip the costly, complicated, and disruptive standardization.

Amber · C · Scroll story

Software inventory

From one artifact to the whole company.

Amber · C · Scroll story

Software inventory

From one artifact to the whole company.

Building inventory…

  1. 01 / 08Artifact

    This is a software artifact.

    One output of software development. It can be traced back to the code that produced it.

    ONE ARTIFACT

  2. 02 / 08Repository

    It comes from code in a repository.

    The repository is the source context for this artifact. Artifacts can be different types, represented here by different colors.

    CODEREPOSITORYARTIFACT

  3. 03 / 08Repositories

    Some repositories produce more than one.

    The outlines are repositories. Each colored block inside one is an artifact; a repository can contain several kinds of output.

    MULTIPLE REPOSITORIESMULTIPLE ARTIFACTS

  4. 04 / 08Application

    Online Banking is an application.

    Artifacts from its repositories become an application inventory. The colored marks show its 395 components; faint squares still identify repository groups.

    APP CODE: OBACOMPONENTS: 395

  5. 05 / 08Applications

    Applications build on the same structure.

    Every new layer repeats the repository groups and component marks. Online Banking, Mobile, Notifications Engine, Event Streaming Platform and Digital Client Onboarding stack together.

    FIVE APPLICATIONSEACH WITH ITS OWN COMPONENTS

  6. 06 / 08Portfolio

    Together, they form Digital Services.

    The five complete application layers sit inside one portfolio. Their repository groups and component inventories remain visible.

    DIGITAL SERVICES PORTFOLIOAPPLICATIONS: 5

  7. 07 / 08Business

    Retail Bank contains seven portfolios.

    A portfolio becomes one repeatable unit. Seven portfolio stacks, each containing applications and their components, form this line of business.

    RETAIL BANKLINE OF BUSINESSPORTFOLIOS: 7

  8. 08 / 08Company

    The whole company.

    Retail Bank, Lending, Wealth Management and Payments each contain portfolios, applications and underlying components.

    TOO MUCH TO COUNT

Compliance readyreleases

Group software assets into releases

Automated watchers sit on every integration in your toolchain. The moment something happens, a scan finishes, a ticket gets approved, a build runs, we record: time stamped record of the raw event. Nothing depends on someone.

Review all changes that impact a release

Every commit, approval and status change that touches a release, in one timeline.

Track compliance across multiple releases

See how each release measures up against your controls, side by side.

Granular policy enforcement that’s
immutable and traceable

  • License scans run on every pull request; anything outside your allow list is stopped before it merges.

    Integration

    1 / 5

    A dependency scanner reports what the pull request would bring in.

    Dependency scanner→ evidence captured by Fianu
    {
      "event": "scan.completed",
      "source": "dependency-scanner",
      "repository": "digital-retail/payments-api",
      "pull_request": 482,
      "commit": "9f3e2c1",
      "components": [
        { "name": "express", "version": "4.19.2", "license": "MIT" },
        { "name": "pg", "version": "8.11.3", "license": "MIT" },
        { "name": "mysql-client", "version": "8.0.33", "license": "GPL-2.0-only" },
        … 212 more
      ]
    }
    Evidence

    Every dependency and the license it declares, attributed to the pull request that introduced it.

    Control

    2 / 5

    Every component's license must appear in the policy's approved list. One license outside it fails the control.

    OSS License Checksubscribes toDependency scanner
    package controls
    import rego.v1
    
    default pass := false
    
    pass if {
      every component in input.evidence.components {
        component.license in policy.approved_licenses
      }
    }
    Result

    Pass or fail, plus the components that violated. Both land in the attestation.

    Policy

    3 / 5

    The approved list lives in Fianu, owned by the people who decide it.

    Policy

    Approved OSS Licenses

    Owner: Open Source Program OfficeVersion 4 · Scope: all repositories

    approved_licenses

    MITApache-2.0BSD-2-ClauseBSD-3-ClauseISCMPL-2.0Unlicense
    Used by OSS License CheckNot listed → control failsExceptions → intake form
    So what

    Changing this list changes the outcome everywhere the control runs. No pipeline edits, no code change.

    Attestation

    4 / 5

    Each evaluation produces a signed attestation that names the exact violation.

    Pull request

    digital-retail/payments-api #482

    commit 9f3e2c1evaluated just now

    Click the badge to view the attestation
    Audit

    Control, policy, and evidence versions are pinned, so the decision can be replayed later and reproduced exactly.

    Gate

    5 / 5

    The merge gate includes the control, so a failing attestation blocks the merge.

    Gate

    Pull Request Merge

    Enforced at: pull requestScope: all repositories

    Controls in this gate

    Code Review Approvalsource-control · review.submitted
    Secret Scansecret-scanner · scan.completed
    OSS License CheckAddeddependency-scanner · scan.completed
    Test Coverage Thresholdtest-runner · run.completed
    Decision: block merge when any control fails
    Enforcement

    Fianu reports the gate decision to the source control platform. PR #482 stays unmergeable until the license is replaced or an exception is approved.

  • Artifacts are promoted only when their evidence meets the CRA controls you've mapped.

    Integration

    1 / 5

    A container registry reports a new artifact, where it came from, and the SBOM that claims to describe it.

    Container registry→ evidence captured by Fianu
    {
      "event": "artifact.pushed",
      "source": "container-registry",
      "repository": "digital-retail/checkout",
      "tag": "2.14.0",
      "digest": "sha256:7c1a…e93f",
      "provenance": {
        "source_repo": "digital-retail/checkout",
        "commit": "b41d0f7",
        "build_id": "ci-58213"
      },
      "attached": {
        "sbom": {
          "format": "spdx-2.3",
          "subject": "sha256:7c1a…e93f",
          "packages": [ "express@4.19.2", "pg@8.11.3", … 185 more ]
        },
        "signature": "present"
      }
    }
    Evidence

    The artifact's content digest, its lineage back to the module and repository, and the SBOM attached to it.

    Control

    2 / 5

    The SBOM must be in an accepted format, must name this artifact's digest as its subject, and must contain every dependency the upstream module declares. That is the CRA's Annex I, Part II (1) requirement made checkable.

    SBOM Coveragesubscribes toContainer registry
    package controls
    import rego.v1
    
    default pass := false
    
    pass if {
      sbom := input.evidence.attached.sbom
      sbom.format in policy.accepted_formats
      sbom.subject == input.evidence.digest
      every dependency in input.upstream.module.dependencies {
        dependency in sbom.packages
      }
    }
    Why this one

    The CRA requires a machine-readable SBOM covering at least top-level dependencies. This control proves the SBOM is real, current, and about this artifact.

    Policy

    3 / 5

    What counts as an acceptable SBOM is set once, by the people accountable for CRA conformity.

    Policy

    EU CRA · SBOM Requirements

    Owner: Product SecurityVersion 2 · Scope: all artifacts

    accepted_formatscommonly used, machine-readablespdx-2.3cyclonedx-1.6
    minimum_depthwhat the SBOM must covertop-level dependencies
    subject_must_match_artifactSBOM digest equals artifact digest
    max_age_daysSBOM generated within1
    Used by SBOM CoverageReference Annex I · Part II (1)
    So what

    When the regulation or your interpretation of it tightens, the policy changes and every artifact is re-evaluated against it.

    Attestation

    4 / 5

    Each evaluation produces an attestation that records what was checked and against which upstream asset.

    Artifact

    digital-retail/checkout:2.14.0

    sha256:7c1a…e93fevaluated just now

    Click the badge to view the attestation
    Audit

    The attestation names the module and commit whose lockfile was compared, so an auditor can see the artifact and its upstream assets were evaluated together.

    Gate

    5 / 5

    One gate holds every control that maps to the CRA. When the artifact and its upstream assets satisfy all of them, the webhook fires.

    Gate

    EU Cyber Res

    Enforced at: artifact promotionScope: all artifacts

    Controls in this gate · 14

    SBOM CoverageEnabledAnnex I · Part II (1) · machine-readable SBOM, top-level dependencies
    No Known Exploitable VulnerabilitiesAnnex I · Part I (2)(a) · nothing on the KEV list ships
    Signed Artifact & Verified ProvenanceAnnex I · Part I (2)(f) · integrity of delivered software
    Coordinated Vulnerability Disclosure PolicyAnnex I · Part II (5) · published and enforced
    Security Update ChannelAnnex I · Part II (7) · secure distribution of updates

    9 more controls

    Enable Webhook on Artifact ComplianceFires once when the artifact and every upstream asset (module, repository) pass all 14 controls. Retracted if any later evidence fails.

    POST https://ci.digital-retail.internal/hooks/promote-to-prod

    Enforcement

    The promotion pipeline runs only when the webhook arrives, so a non-compliant artifact never reaches the production registry.

  • Pipelines on an outdated shared library are flagged and held until they're updated.

    Integration

    1 / 5

    The source control platform exposes each workflow file and which version of the enterprise-tooling reusable workflows it pins.

    Source control platform→ evidence captured by Fianu
    {
      "event": "push",
      "source": "source-control",
      "repository": "digital-retail/orders-service",
      "ref": "refs/heads/main",
      "commit": "e77b2a4",
      "workflows": [
        {
          "path": ".ci/workflows/build.yml",
          "uses": [
            "enterprise-tooling/container-build@v2.4.1",
            "enterprise-tooling/k8s-deploy@v3.0.0"
          ]
        },
        … 2 more
      ]
    }
    Evidence

    Each workflow file on the default branch and the reusable workflow versions it pins.

    Control

    2 / 5

    Every library a workflow pins must be at or above the minimum the policy sets for it. Libraries the policy doesn't list default to v0.0.0, so they always pass.

    Pipeline Versionsubscribes toSource control platform
    package controls
    import rego.v1
    
    default pass := false
    
    pass if {
      every workflow in input.evidence.workflows {
        every reference in workflow.uses {
          [library, version] := split(reference, "@")
          minimum := object.get(policy.minimum_versions, library, "v0.0.0")
          semver.compare(
            trim_prefix(version, "v"),
            trim_prefix(minimum, "v")
          ) >= 0
        }
      }
    }
    Result

    Pass when every library in use meets or exceeds its minimum. Libraries the workflow doesn't use are ignored.

    Policy

    3 / 5

    Platform Engineering keeps one list of minimum versions. A workflow is measured only against the libraries it uses.

    Policy

    Pipeline Library Minimums

    Owner: Platform EngineeringVersion 11 · Scope: all workflows

    minimum_versions · 8 libraries

    enterprise-tooling/container-buildIn usev2.4.0
    enterprise-tooling/k8s-deployIn usev3.0.0
    enterprise-tooling/unit-testv1.9.2
    enterprise-tooling/sast-scanv4.1.0
    enterprise-tooling/sbom-generatev2.0.0
    enterprise-tooling/artifact-signv1.3.0

    3 more libraries

    Used by Pipeline VersionApplies to libraries a workflow uses
    So what

    Raising one minimum here re-evaluates every workflow that pins that library. Teams that don't use it are untouched.

    Attestation

    4 / 5

    The attestation records each library in use, the version pinned, the minimum it was measured against, and how much room is left.

    Workflow

    orders-service · .ci/workflows/build.yml

    commit e77b2a4evaluated just now

    Click the badge to view the attestation
    So what

    A pass that still carries a warning: k8s-deploy sits exactly at the minimum, so the next policy bump fails this workflow unless it moves first.

    Gate

    5 / 5

    One gate, three enforcement points: block the build, block the deployment, and warn at merge before either happens.

    Gate

    Pipeline Integrity

    Scope: all workflows

    Controls in this gate

    Pipeline VersionEnabledsource-control · push
    Approved Runner Poolci-platform · run.started
    Pinned Action Digestssource-control · push

    Enforcement when a control fails

    CI pipeline buildworkflow run is stopped before it startsBlock
    CD pipeline deploymentdeployment is stopped before it startsBlock
    Pull request mergepush notification to the author and repo owners when workflow files are behind minimumNotify
    Enforcement

    Teams hear about it at merge, when the fix is a one-line version bump. Anything that still slips through is stopped at build and again at deploy.

  • Dependency evidence is checked at the deploy gate, so a vulnerable Log4j never reaches production.

    Integration

    1 / 5

    An SCA platform reports what it found in the image and ties it back to the repository and commit that built it.

    SCA platform→ evidence captured by Fianu
    {
      "event": "sca.completed",
      "source": "sca",
      "image": "digital-retail/inventory-api",
      "digest": "sha256:4b8e…a217",
      "repository": "digital-retail/inventory-api",
      "commit": "c58d19e",
      "tag": "3.7.2",
      "findings": [
        {
          "component": "org.apache.logging.log4j:log4j-core",
          "version": "2.14.1",
          "cve": "CVE-2021-44228",
          "severity": "critical",
          "cvss": 10.0
        },
        … 3 more
      ]
    }
    Evidence

    Every finding against the image, keyed to the image digest and to the repository and commit it was built from.

    Control

    2 / 5

    No finding may carry a CVE that appears on the priority remediation list.

    Priority Remediationsubscribes toSCA platform
    package controls
    import rego.v1
    
    default pass := false
    
    pass if {
      every finding in input.evidence.findings {
        not policy.cves[finding.cve]
      }
    }
    Result

    Fail on a single match. The matched finding, component, and version go into the attestation.

    Policy

    3 / 5

    The security team keeps the list of CVEs that must never reach production. Adding one re-evaluates every artifact.

    Policy

    Priority Remediation

    Owner: Security OperationsVersion 23 · Scope: all artifacts

    cves · 12 listed

    CVE-2021-44228 Log4ShellMatchedApache Log4j 2 · remote code execution10.0
    CVE-2017-5638 StrutsApache Struts 2 · remote code execution10.0
    CVE-2024-3094 XZ Utilsliblzma · supply chain backdoor10.0
    CVE-2020-1472 ZerologonNetlogon · privilege escalation10.0
    CVE-2019-11510 Pulse SecureVPN · arbitrary file read10.0
    CVE-2024-1709 ScreenConnectauthentication bypass10.0

    7 more CVEs

    Used by Priority RemediationReviewed weekly
    So what

    The day a new Log4j lands, one line added here finds every affected artifact and stops every affected deployment.

    Attestation

    4 / 5

    The attestation names the CVE, the component carrying it, and the commit that introduced it.

    Artifact

    digital-retail/inventory-api:3.7.2

    sha256:4b8e…a217evaluated just now

    Click the badge to view the attestation
    Audit

    Months later, the question "did anything with Log4Shell reach production?" is answered by these records, with the policy version that was in force.

    Gate

    5 / 5

    Everything that must be true before production, in one gate. Releases hear about a failure early; deployments are stopped on the spot.

    Gate

    Production Deploy

    Environment: ProdScope: all targets

    Controls in this gate · 9

    Priority RemediationEnabledsca · sca.completed
    Code Review Approvalsource-control · review.submitted
    Artifact Versioncontainer-registry · immutable, semantic tag
    Change Record Approvalchange-management · record.approved
    Test Coverage Thresholdtest-runner · run.completed

    4 more controls

    Enforcement when any control fails

    Releaserelease owners are warned as soon as any artifact in the release fails, before a deployment is attemptedWarn
    Deployment to Prodstopped immediately, whichever pipeline or method is deployingBlock
    Enforcement

    inventory-api 3.7.2 cannot reach any Prod target until the finding is remediated or an exception is approved. The release carrying it already knows.

Integration

1 / 5

A container registry reports a new artifact, where it came from, and the SBOM that claims to describe it.

Container registry→ evidence captured by Fianu
{
  "event": "artifact.pushed",
  "source": "container-registry",
  "repository": "digital-retail/checkout",
  "tag": "2.14.0",
  "digest": "sha256:7c1a…e93f",
  "provenance": {
    "source_repo": "digital-retail/checkout",
    "commit": "b41d0f7",
    "build_id": "ci-58213"
  },
  "attached": {
    "sbom": {
      "format": "spdx-2.3",
      "subject": "sha256:7c1a…e93f",
      "packages": [ "express@4.19.2", "pg@8.11.3", … 185 more ]
    },
    "signature": "present"
  }
}
Evidence

The artifact's content digest, its lineage back to the module and repository, and the SBOM attached to it.

Control

2 / 5

The SBOM must be in an accepted format, must name this artifact's digest as its subject, and must contain every dependency the upstream module declares. That is the CRA's Annex I, Part II (1) requirement made checkable.

SBOM Coveragesubscribes toContainer registry
package controls
import rego.v1

default pass := false

pass if {
  sbom := input.evidence.attached.sbom
  sbom.format in policy.accepted_formats
  sbom.subject == input.evidence.digest
  every dependency in input.upstream.module.dependencies {
    dependency in sbom.packages
  }
}
Why this one

The CRA requires a machine-readable SBOM covering at least top-level dependencies. This control proves the SBOM is real, current, and about this artifact.

Policy

3 / 5

What counts as an acceptable SBOM is set once, by the people accountable for CRA conformity.

Policy

EU CRA · SBOM Requirements

Owner: Product SecurityVersion 2 · Scope: all artifacts

accepted_formatscommonly used, machine-readablespdx-2.3cyclonedx-1.6
minimum_depthwhat the SBOM must covertop-level dependencies
subject_must_match_artifactSBOM digest equals artifact digest
max_age_daysSBOM generated within1
Used by SBOM CoverageReference Annex I · Part II (1)
So what

When the regulation or your interpretation of it tightens, the policy changes and every artifact is re-evaluated against it.

Attestation

4 / 5

Each evaluation produces an attestation that records what was checked and against which upstream asset.

Artifact

digital-retail/checkout:2.14.0

sha256:7c1a…e93fevaluated just now

Click the badge to view the attestation
Audit

The attestation names the module and commit whose lockfile was compared, so an auditor can see the artifact and its upstream assets were evaluated together.

Gate

5 / 5

One gate holds every control that maps to the CRA. When the artifact and its upstream assets satisfy all of them, the webhook fires.

Gate

EU Cyber Res

Enforced at: artifact promotionScope: all artifacts

Controls in this gate · 14

SBOM CoverageEnabledAnnex I · Part II (1) · machine-readable SBOM, top-level dependencies
No Known Exploitable VulnerabilitiesAnnex I · Part I (2)(a) · nothing on the KEV list ships
Signed Artifact & Verified ProvenanceAnnex I · Part I (2)(f) · integrity of delivered software
Coordinated Vulnerability Disclosure PolicyAnnex I · Part II (5) · published and enforced
Security Update ChannelAnnex I · Part II (7) · secure distribution of updates

9 more controls

Enable Webhook on Artifact ComplianceFires once when the artifact and every upstream asset (module, repository) pass all 14 controls. Retracted if any later evidence fails.

POST https://ci.digital-retail.internal/hooks/promote-to-prod

Enforcement

The promotion pipeline runs only when the webhook arrives, so a non-compliant artifact never reaches the production registry.

Join the Community waitlist

Book a demo

Want to hear more? We’ll call you