By Louise Grosset and François-Régis Menguy, Orange – Sylva WG03
Sylva’s security work leans heavily on the OpenSSF ecosystem. We started with supply chain tooling, using Sigstore for signing, and SLSA as our maturity framework. We then adopted OpenSSF Scorecard and the Best Practices Badge, and recently began a CRA readiness effort based on the OpenSSF CRA Readiness Guide. This post shares what we did, what worked and what is still hard.
Why we started with the supply chain
Our starting point was a simple question: how can an operator trust what it deploys? For Sylva, that means protecting artifacts against tampering at every stage of their lifecycle. It also means verifying the trustworthiness of what we produce and of what we consume from upstream.
We organised this work around the following building blocks.
Source integrity. We require at least two approvals before merging major changes, plus branch protection and commit validation. 2FA is enforced.
Build integrity. Our CI runs static analysis and linters, builds SBOMs and scans container images (we use Trivy and Dependency-Track). The goal is to decide whether an artifact can be trusted before it is released.
Signing and attestation. Artifacts that pass these checks are signed and attested with Sigstore (cosign, in-toto attestations). We aim for SLSA Level 3.
Upstream artifacts. Open source dependencies are rarely signed or attested, so SLSA’s advice to verify the provenance of dependencies is hard to follow in practice. We scan, build SBOMs, validate and patch where needed, then sign and attest our own validation. A vulnerability assessment committee reviews external artifacts. Zero-trust applies throughout.
Where we stand
We assess each type of artifact separately, because maturity differs a lot from one to the next.
| Artifact | Status |
|---|---|
| OS images (OCI) | Signed and verified, with provenance and SBOM attestation |
| Helm charts (OCI) | Signed and verified, attestation in progress |
| Kubernetes operators, sylva-core, sylvactl | Static analysis and signing in place, SBOM and attestation ongoing |
| Upstream images | Scanning and SBOM ongoing; signing and attestation are the most painful part |
Signing with Sigstore is in place for our own artifacts, attestation and SLSA are still in progress, and nested components (a Helm chart that embeds images and other charts) remain our hardest problem. Proving the integrity of something that wraps several third-party components is much harder than proving the integrity of a single binary.
What Sigstore and SLSA gave us
Sigstore: verifiable artifacts. Signing and attestation with cosign and in-toto attestations now covers our artifact types to varying degrees (see the table above). For operators, this means they can verify what they deploy instead of simply trusting it.
SLSA: a shared maturity framework. SLSA gave us a common vocabulary and a target. OS images already ship with provenance and SBOM attestation, and we aim for Level 3 across the project. Three difficulties stand out:
- GitLab. SLSA Level 3 is not fully available on GitLab runners today. We are working on an incremental approach.
- Nested components. A Helm chart that embeds images and other charts needs more than one attestation to prove its integrity end to end.
- Upstream dependencies. SLSA recommends verifying the provenance of what you consume, but most open source dependencies are neither signed nor attested. We scan them, build SBOMs, validate and patch where needed, then sign and attest our own validation.
If you are starting out, we would suggest signing a first artifact type end to end before trying to cover everything, and treating each SLSA level as an incremental goal rather than a pass/fail test.
Adopting OpenSSF Scorecard
We wanted an objective, repeatable way to measure our security posture and track its evolution, rather than relying on self-assessment alone. Scorecard offered exactly that. We started with our main repository, sylva-core, as a proof of concept to test how relevant the tool was for us. Once we saw its value, we integrated it into our shared CI templates so that it can be used across all Sylva repositories.
What Scorecard gave us. A baseline we can track over time and a short list of concrete actions. For example, it pointed to the missing security policy on sylva-core and the Security-Policy score went from 0 to 10 once we published SECURITY.md. The rollout to the other Sylva repositories is in progress.
The GitLab question. Sylva’s development happens on GitLab, while Scorecard was designed around GitHub, so some checks are limited or not applicable on our setup. As a result, good practices can be underreported. On recent sylva-core commits, about 94% of changes were reviewed, but Scorecard reports about 65%. Some checks also fit an infrastructure project poorly, such as fuzzing or signed releases stored in an OCI registry. We also follow the Scorecard roadmap closely. Some upcoming features, such as OSPS Baseline conformance checks, would be very useful for our CRA work, but they are planned for GitHub first. We hope to see them on GitLab soon.
Our advice for anyone starting:
- Run Scorecard early, and treat the first result as a baseline rather than a verdict.
- Look at the individual checks, not just the aggregate score, and decide which ones matter most for your threat model.
- Know your platform’s limits before you interpret a low score.
- Make the result visible to your community; it creates helpful pressure.
The OpenSSF Best Practices Badge
In parallel, we started the self-assessment for sylva-core. When we started, we met 93% of the passing criteria. The missing piece was a coordinated vulnerability disclosure (CVD) process. It is now documented in our SECURITY.md and was validated by the Sylva Technical Steering Committee. We have just done a new assessment pass, and we now meet 96% of the silver-level criteria. The two remaining gaps are quick to close: adopting a code of conduct and publishing it in a standard location, and linking our achievements, including the badge itself, from the repository front page.
The CVD gap pushed us to do work we needed anyway. WG03 published the CVD process and a reporting template, and a CVE management process covering all Sylva releases. We see this as a good example of the badge doing its job: it points at what is missing and gives it a concrete deadline.
First steps toward CRA readiness
Sylva is used by telecom operators and vendors who, when they place products on the EU market, must comply with the Cyber Resilience Act. An open source project like Sylva isn’t in that position itself, and the OpenSSF’s CRA Readiness Guide for Maintainers and Developers is clear on this point: the responsibility for due diligence stays with the manufacturer and cannot be shifted upstream to maintainers. “CRA readiness” is not a certification or a legal status. It is a voluntary transparency practice.
That is how we approached it. Our goal is to make it easier for downstream integrators to do their own due diligence, without having to interrupt the project team with questionnaires. We opened a dedicated epic in the Sylva GitLab group and used the OpenSSF CRA Readiness Guide as our checklist, along with the OSPS Baseline, the Security Insights spec and the OpenSSF Best Practices criteria.
The guide proposes a short “CRA-friendly” checklist. Here is how it maps to Sylva today:
| Practice | Sylva status |
|---|---|
| Vulnerability management policy | Published in SECURITY.md: a CVD process with a reporting template, a confidential handling commitment and a public advisory once fixed. |
| Contributing guidance | Contribution guide on the Sylva documentation portal, CONTRIBUTING.md in progress |
| Release documentation, including security fixes | Release notes list new features by topic, including security, as well as patches |
| Bug reporting guide, distinct from security reporting | GitLab issues with a bug template, separate from the confidential security channel |
| MFA enforcement | Enabled on GitLab |
| Branch protection | Two approvals required for major changes, branch protection and push rules |
| License file | Apache 2.0, in a LICENSE file at the root of the repository |
| OSPS Baseline Level 1 | Self-assessment done for sylva-core, remaining gaps tracked in our CRA epic |
Two choices are worth mentioning.
Working with a CRA steward. Our SECURITY.md states that Sylva is supported under the Linux Foundation’s CRA stewardship framework. Vulnerabilities reported through our CVD process are coordinated with that steward, and actively exploited vulnerabilities or severe incidents that could require CRA escalation follow the project’s emergency reporting mechanisms. For a project hosted at Linux Foundation Europe, this gives us a clear path for the cases where reporting obligations may come into play.
Human- and machine-readable. The guide recommends documenting readiness in a human-readable form (the checklist, with an explicit disclaimer that the project has no CRA obligations and gives no compliance assurances), and optionally in a machine-readable form such as a Security Insights file. We plan to do both. Together with Scorecard results and our signed, attested artifacts with SBOMs, this gives integrators something they can check automatically.
This work builds on what we described above: the CVD and CVE processes, the vulnerability assessment committee, SBOMs generated throughout the pipeline, and signing with Sigstore. It is separate from our EUCS mapping and our Hardening Guide, which target operators’ own compliance needs.
Join the conversation
We’d love to hear from other projects facing similar challenges, especially those on GitLab or with complex, nested artifacts. If you’d like to compare notes or contribute, reach out through the Sylva community, the WG03 repository on GitLab, or the OpenSSF channels. Thanks to the OpenSSF community for the tools and the discussions that helped us get this far.
