Lino 2.0 is Safeguard.sh's compliance model and it is generally available today. Lino's job is narrow and unglamorous: given an artifact, a finding, or a workflow output, map it to the relevant controls in the frameworks that actually govern your organization, with enough evidence that an auditor does not have to re-derive the mapping themselves.
The 2.0 release is the first version where Lino treats frameworks as a first-class composition problem rather than picking one framework and projecting everything onto it. That matters in practice because most customers we work with operate under at least three frameworks concurrently, and the accidents of the old "primary framework" assumption showed up as gaps at audit time.
What frameworks does Lino 2.0 support, and how does multi-jurisdiction mapping work?
Answer first: Lino 2.0 supports 14 frameworks out of the box and treats them as independent projections over the same evidence set.
The supported list is SOC 2 (2017 Trust Services Criteria), ISO 27001:2022, ISO 27017, ISO 27018, NIST SP 800-53 Rev. 5 (low/moderate/high/high-plus), NIST SP 800-171 Rev. 3, FedRAMP Moderate, FedRAMP High, DoD IL4, DoD IL5, DoD IL7, CIS Controls v8.1, PCI DSS v4.0.1, HIPAA Security Rule, and GDPR Article 32 technical measures. New in 2.0: India DPDP Act technical safeguards, Australia Essential Eight, UK NCSC CAF, and EU NIS2 technical requirements.
The change from 1.5 is that Lino no longer requires you to pick a "primary" framework. In 1.5, you selected one framework per workspace and everything else was shown as a secondary overlay. In 2.0, every evidence item is mapped independently to every framework the workspace is subscribed to. The web app shows a matrix: rows are controls, columns are frameworks, cells are the evidence items that satisfy them. The same evidence item can satisfy a SOC 2 CC7.1 control and a FedRAMP SI-2 control simultaneously, and Lino does not double-count.
The practical reason for this design: customers who run workloads in both FedRAMP HIGH and commercial environments were previously maintaining two parallel Safeguard configurations. In 2.0, a single workspace with both frameworks enabled produces evidence that satisfies both, and the audit exports split along framework lines automatically.
What counts as "evidence" in Lino 2.0?
Evidence is the artifact-plus-action trail that Lino attaches to each control mapping, and in 2.0 it is structured rather than free-text.
Each evidence item has five fields: the control it maps to, the artifact or workflow run that produced it, the timestamp, the signer (a Safeguard service identity or a human approver), and a kind. The kinds are finding.closed, policy.enforced, attestation.signed, workflow.completed, and review.approved. Auditors get a consistent shape across evidence; automation gets a predictable field to key off.
An example: a Griffin remediation run that closes a CVE in a FedRAMP-scoped service produces a finding.closed evidence item mapped to NIST 800-53 SI-2. The item references the Eagle finding ID, the Griffin run ID, the resulting PR, and the signer — a human reviewer if approval was required, the Safeguard workflow service identity otherwise. Lino 2.0 carries this through to the audit export without asking you to re-attest.
{
"control": "NIST-800-53:SI-2",
"framework": "FedRAMP-High",
"kind": "finding.closed",
"artifact": "pkg:npm/lodash@4.17.19",
"workflow_run": "run_01J8X9...",
"signer": {
"type": "human",
"subject": "jane.doe@example.com",
"role": "security-approver"
},
"timestamp": "2026-02-03T18:22:11Z",
"lino_version": "2.0"
}
The important behavior: evidence is append-only. You cannot edit an evidence item; you can supersede it with a newer one, and the audit export shows both. This matches how most auditors want to see the trail.
How do exports for audits work?
Answer first: there is a single lino export command that produces an audit package scoped to a framework and a date range, and it is the canonical output for auditors.
The package is a signed .tar.gz containing the control-to-evidence matrix as JSON, a human-readable summary as PDF, the individual evidence items as JSON files, and a manifest with the signing key fingerprint. The signature is a Sigstore bundle; the key is rotated quarterly and the rotation log is inside the package. Auditors who are not Sigstore-aware can verify the SHA-256 manifest by hand; those who are can run cosign verify-blob against the bundle.
The export is deterministic given the same inputs — running it twice over the same date range on the same workspace produces byte-identical archives, which is a property auditors ask for surprisingly often.
safeguard lino export \
--framework fedramp-high \
--from 2025-11-01 --to 2026-01-31 \
--workspace acme-prod \
--out ./audit-q4-fedramp.tar.gz
For customers with continuous monitoring requirements — FedRAMP HIGH, IL7, PCI DSS — Lino 2.0 can stream evidence to a Sigstore-backed transparency log rather than batch it. The stream is the same shape as the batch export; it is just chunked. Turning this on is a per-workspace setting and the default for new Gov-region workspaces.
What should I check before upgrading from 1.5?
Three things to review before flipping a workspace to 2.0: the framework list, any custom controls, and the retention policy on evidence.
The framework list: 2.0 requires you to explicitly enable each framework you want evidence for, rather than inheriting from a primary. If you ran 1.5 with SOC 2 as primary and implicitly cared about FedRAMP via overlays, you now need to enable both explicitly. The migration assistant in the web app will pre-populate this based on your 1.5 config but you should verify.
Custom controls: 1.5 let you define custom controls as free-text. 2.0 requires custom controls to have a schema — a control ID, a description, a parent framework, and a list of acceptable evidence kinds. The migration tool will flag any custom control that does not fit the schema and block the upgrade until you either map it to a built-in control or fill in the schema.
Retention: the default retention for Lino evidence in 2.0 is seven years for regulated workspaces (FedRAMP, PCI, HIPAA, IL4+) and two years for commercial. If your 1.5 workspace had a different retention, the migration preserves it but flags it. Changing retention downward after the upgrade is a one-way action and requires two approvers.
The grace period to run 1.5 alongside 2.0 is four months. After that, 1.5 will continue to serve existing evidence (which does not expire) but will not produce new evidence items.
How Safeguard.sh Helps
Lino 2.0 is the compliance layer across the whole platform, which means the evidence it produces comes from every other piece — Griffin remediation runs, Eagle classification outputs, Gold Registry attestations, workflow runs from the 50+ template library, and the TPRM vendor module. The multi-jurisdiction model removes the need to run parallel workspaces for customers who operate in both commercial and regulated environments; a single workspace with FedRAMP HIGH, IL7, and SOC 2 Type II enabled produces audit exports for each. Evidence flows through the MCP Server, the desktop application, the Local Runner, and the IDE extensions — any action taken in those surfaces that satisfies a control lands in Lino without a separate attestation step. If you are preparing for a 3PAO assessment, the deterministic, Sigstore-signed export is designed to be the artifact you hand over.