How Sylva Built Supply Chain Security With OpenSSF Tools

Sylva, an open source initiative serving telecom operators and vendors, has constructed its security infrastructure around a suite of tools from the OpenSSF. The project began by asking a fundamental question: how can an operator trust the software it deploys? That inquiry led to a multi-layered approach spanning artifact signing, supply chain verification, and readiness for the European Union's Cyber Resilience Act.

Building Blocks of Trust

Sylva organized its security work into four distinct areas. Source integrity relies on requiring at least two approvals before merging major changes, along with branch protection, commit validation, and mandatory two-factor authentication. Build integrity involves running static analysis and linters during continuous integration, generating software bill of materials (SBOMs), and scanning container images using Trivy and Dependency-Track to determine whether artifacts merit release. Signing and attestation uses Sigstore—specifically cosign and in-toto attestations—with the goal of reaching SLSA Level 3. Upstream artifacts present a harder challenge: open source dependencies typically lack signatures or attestations, so Sylva scans them, builds SBOMs, validates and patches them, then signs and attests its own validation work. A vulnerability assessment committee reviews external artifacts throughout.

The project assesses each artifact type separately because maturity varies considerably. Sigstore signing is operational for Sylva's own artifacts, though attestation and SLSA remain works in progress. Nested components—such as Helm charts that bundle images and other charts—pose the greatest difficulty. Proving the integrity of a container that wraps multiple third-party components demands far more effort than validating a single binary.

Sigstore and SLSA: Verification and Maturity

Sigstore enables operators to verify artifacts rather than simply accepting them on faith. Cosign and in-toto attestations now cover Sylva's artifact types to varying degrees. SLSA provides a shared vocabulary and measurable targets; OS images already include provenance and SBOM attestation, and the project aims for Level 3 across the board.

Three obstacles stand out. GitLab does not yet fully support SLSA Level 3 on its runners, forcing an incremental approach. Nested components require multiple attestations to prove end-to-end integrity. Upstream dependencies present the most stubborn problem: SLSA recommends verifying the provenance of consumed code, but most open source dependencies carry neither signatures nor attestations.

For projects starting out, Sylva recommends signing a single artifact type end to end before attempting comprehensive coverage, and treating each SLSA level as an incremental milestone rather than a binary pass-or-fail threshold.

Scorecard: Objective Measurement

Sylva sought an objective, repeatable method to measure security posture and track improvement over time, moving beyond self-assessment. OpenSSF Scorecard delivered exactly that. The project piloted the tool on its main repository, sylva-core, then integrated it into shared CI templates for use across all Sylva repositories.

Scorecard provided a baseline that can be tracked over time and a concrete list of actions. When the tool flagged a missing security policy on sylva-core, the team published SECURITY.md and the Security-Policy score jumped from 0 to 10. Rollout to other Sylva repositories is ongoing.

Scorecard was designed around GitHub, and Sylva develops on GitLab, creating limitations. Some checks do not apply to the setup, causing good practices to be underreported. On recent sylva-core commits, approximately 94% of changes underwent review, but Scorecard reported about 65%. Certain checks also fit poorly with an infrastructure project—fuzzing and signed releases in an OCI registry, for example. Sylva monitors the Scorecard roadmap closely; upcoming features such as OSPS Baseline conformance checks would aid CRA work but are planned for GitHub first.

Sylva offers four recommendations for other teams:

1. Run Scorecard early, treating the first result as a baseline rather than a verdict.
2. Examine individual checks rather than the aggregate score, and decide which ones matter most for your threat model.
3. Understand your platform's limits before interpreting a low score.
4. Make the result visible to your community; it creates helpful pressure.

Best Practices Badge and Vulnerability Disclosure

Sylva began self-assessment for the OpenSSF Best Practices Badge on sylva-core and initially met 93% of the passing criteria. The missing element was a coordinated vulnerability disclosure (CVD) process. The team documented this in SECURITY.md and obtained validation from the Sylva Technical Steering Committee. A subsequent assessment pass showed the project now meets 96% of silver-level criteria. Two gaps remain: adopting a code of conduct and publishing it in a standard location, and linking achievements including the badge itself from the repository front page.

The CVD gap prompted necessary work. WG03 published a CVD process and reporting template, plus a CVE management process covering all Sylva releases. The badge functioned as intended: it identified what was missing and imposed a concrete deadline.

CRA Readiness: Transparency Without Obligation

Sylva is deployed by telecom operators and vendors who must comply with the Cyber Resilience Act when placing products on the EU market. An open source project like Sylva itself faces no such requirement. The OpenSSF's CRA Readiness Guide for Maintainers and Developers makes this clear: the responsibility for due diligence rests with the manufacturer and cannot be transferred upstream to maintainers. "CRA readiness" is not a certification or legal status—it is a voluntary transparency practice.

Sylva approached it as a way to simplify due diligence for downstream integrators, eliminating the need to interrupt the project team with questionnaires. The team opened a dedicated epic in the Sylva GitLab group and used the OpenSSF CRA Readiness Guide as a checklist, supplemented by the OSPS Baseline, the Security Insights spec, and the OpenSSF Best Practices criteria.

Two choices merit attention. Sylva's SECURITY.md states that the project is supported under the Linux Foundation's CRA stewardship framework. Vulnerabilities reported through the CVD process are coordinated with that steward, and actively exploited vulnerabilities or severe incidents that could trigger CRA escalation follow the project's emergency reporting mechanisms. For a project hosted at Linux Foundation Europe, this provides a clear path for cases where reporting obligations may apply.

The guide recommends documenting readiness in human-readable form—the checklist with an explicit disclaimer that the project has no CRA obligations and provides no compliance assurances—and optionally in machine-readable form such as a Security Insights file. Sylva plans to do both. Combined with Scorecard results and signed, attested artifacts bearing SBOMs, this gives integrators material they can verify automatically.

This work rests on the CVD and CVE processes, the vulnerability assessment committee, SBOMs generated throughout the pipeline, and Sigstore signing described earlier. It remains separate from Sylva's EUCS mapping and Hardening Guide, which address operators' own compliance needs.

About the Authors

François-Régis Menguy is a security engineer at Orange, focused on infrastructure security and DevSecOps. He leads the Security working group (WG03) of the Sylva project, where he drives the adoption of OpenSSF tooling and CRA readiness practices. Louise Grosset is a cybersecurity apprentice at Orange, in a work-study program with ESNA in Rennes, France. Louise contributes to the Security working group of the Sylva project, where she helped integrate OpenSSF tools and carried out the CRA readiness study.