Sample repository
A new organisation has nothing to scan until it pushes code. To see what the security features do before that, an org owner can copy fremforge’s security sample into the organisation: a small repository with deliberately outdated dependencies, so findings, reachability verdicts and a security fix pull request appear within minutes.
Create it
On Security › Overview (/<org>/_admin/security/overview), the Scan coverage item of the setup checklist has a Try it on a sample repository button. Org owners can use it; it is refused for auditors like every change.
- It creates
<org>/fremforge-security-sample, a private repository, and commits the sample into it in one commit byfremforge. The repository is scanned as soon as it is created. - An organisation can have one sample repository. Clicking again says it already exists.
- If a repository named
fremforge-security-samplealready exists, nothing is created; rename or delete that repository first. - Every attempt is in the audit log as
code-security.sample_repo.created, with the outcome.
What is in it
The content comes from a fixed, reviewed commit of fremforge’s own sample. It holds manifests, lockfiles and a few lines of code that call the vulnerable functions. The dependencies’ own source code is not included. Nothing in it is built, run or deployed: there are no workflows and no Dockerfile. It is licensed MIT, and its README names the advisories it is meant to show:
| Ecosystem | Package | Version | Advisory | Reachability |
|---|---|---|---|---|
| npm | lodash | 4.17.20 | CVE-2021-23337 (command injection in template) | reachable: the sample calls template |
| npm | lodash | 4.17.20 | CVE-2020-28500 (ReDoS) | no call path |
| npm | minimist | 1.2.5 | CVE-2021-44906 (prototype pollution) | no call path: listed, never imported |
| Go | golang.org/x/text | v0.3.5 | GO-2021-0113 / CVE-2021-38561 (language.ParseAcceptLanguage) | reachable: the sample calls it |
| PyPI | PyYAML | 5.3.1 | CVE-2020-14343 (code execution through full_load) | reachable at import level |
The pinned versions carry a few more advisories than these. Each has a fixed version, so Open fix PR works for all of them. If your organisation has automatic security fixes switched on, fix pull requests open on the sample by themselves, as they would on any repository.
Console only
Findings on the sample repository show in the console and the API, like any other. They never leave fremforge:
- no security alert mail, immediate or in the daily summary, and nothing about them in the weekly security digest;
- no alert webhook and no SIEM event, including the finding-derived audit events (scan ingests, matches, SLA breaches);
- never counted in anonymous counts, and an organisation whose only repository is the sample contributes nothing to them;
- never counted in fremforge’s own measurements of its security features.
The sample is never counted as scan coverage either: the checklist item still asks for a repository of your own.
When it stops being a sample
The sample is fremforge’s content only while its default branch is where fremforge left it. As soon as anyone pushes to, or merges into, its default branch (merging one of its fix pull requests counts), it becomes an ordinary repository: from then on its findings send alerts, webhooks and SIEM events, count in anonymous counts and as scan coverage, like any other repository. This is recorded in the audit log as code-security.sample_repo.graduated. Pushes to other branches, such as a fix pull request’s branch, change nothing.
Remove it
Delete the repository in Forgejo when you are done. fremforge notices the deletion and forgets the sample, so you can create a new one later. Renaming it keeps it a sample.