Skip to content

Add Ferralon Assay - #1

Open
openferralon[bot] wants to merge 1 commit into
masterfrom
ferralon-assay
Open

openferralon[bot] wants to merge 1 commit into
masterfrom
ferralon-assay

Conversation

@openferralon

@openferralon openferralon Bot commented Nov 3, 2026

Copy link
Copy Markdown

Important

travisbgreen/PCredz is a fork, and GitHub disables GitHub Actions on a fork by default, so the assay workflow will not run there until Actions is turned on. Open the repository's Actions tab and enable workflows for this fork (Settings → Actions → General → Allow all actions). Ferralon cannot turn Actions on for you — that is a repository-administration setting the App is not granted.

This pull request adds .github/workflows/ferralon-assay.yml — the entire Ferralon footprint this installs into your repository. It is one file: a GitHub Actions workflow that runs a free, deterministic dependency-advisory scan in your own runner, on your own token. The analysis never runs on Ferralon's infrastructure. No other file is added; the scan stores its own baseline on a separate state ref, named in the workflow's with: block below.

What the run downloads. The ferralon-ai/ferralon-assay Action, pinned on its uses: line to a full commit SHA, fetches one scanner release: the one that version of the Action names. Every action the workflow uses is pinned to a full commit SHA.

Past that, the scan drives your language's ordinary build and advisory toolchain and reaches the same public services that toolchain always does — for Go, the module proxy (proxy.golang.org) whenever the runner's module cache is cold, and the Go vulnerability database (vuln.go.dev). Those requests name the modules being resolved or checked; they carry no source code, and they go to the same services a plain go build and govulncheck in this workflow would already contact.

What leaves your repository to Ferralon. Every request this workflow makes to Ferralon is decided by one line in the job's env: — FERRALON_LINK_TO_CONSOLE: true, right there in this diff — which the assay step passes on as its link-to-console input. While it is true, the run makes these requests and no others. None carries your source code.

  • At the start of each run, the workflow's scan-window step makes one request to the SCAN_WINDOW_URL written out in it, to read the scan window set in your Ferralon console; it sends the run's GitHub OIDC token, which names your repository, its owner and the run. If that request fails it uses the window written beside it and says why; it never fails the job.
  • To runs-url, on runs that analyzed your repository's canonical ref — its default branch, unless a .github/ferralon.yml names another under analyze.ref — the scan posts its assessment so you can read it in the Ferralon console. That assessment lists your dependencies, which advisories matched them, and — for a reachable finding — the function names and file:line where your code reaches the affected dependency. It carries no source file contents.
  • To ingest-url, on every run, the scan posts your repository owner and name, the commit SHA, and the advisory id when a re-scan was advisory-triggered. This is also the channel that tells the scan the Ferralon App was uninstalled, which is what lets it remove itself.

All are best-effort: an unreachable endpoint is logged and the run still succeeds. To switch them all off, set that one line to false — or delete it, which does the same thing —

      FERRALON_LINK_TO_CONSOLE: false

The scan-window step then uses the window written into it without asking, and the scan, the code-scanning upload, the pull-request comment, the Issue and the report artifact all keep working either way. Turning it off also switches off self-removal, because the uninstall signal arrives on that channel.

All three addresses are written out in the workflow, so the file names every place a run sends data. Emptying an address does not switch it off; FERRALON_LINK_TO_CONSOLE is the switch.

Removal is reversible and honest. This file removes itself when the Ferralon App is uninstalled; deleting it manually is also safe — the state ref cleans itself up either way.

It was opened automatically by the Ferralon install provisioner. The scaffold is committed to a dedicated ferralon-assay branch (your default branch is untouched) so you can review it before merging. Merge this PR to enable the assay.

Adds .github/workflows/ferralon-assay.yml — the entire Ferralon footprint this installs into this repository. It is one file: a GitHub Actions workflow that runs a free, deterministic dependency-advisory scan in this repository's own runner, via the ferralon-ai/ferralon-assay Action, pinned to a full commit SHA. Nothing else is committed.

Every request it makes to Ferralon is gated on one switch, FERRALON_LINK_TO_CONSOLE in the job's env, which the assay step passes on as link-to-console. While it is true, its scan-window step reads the scan window from the Ferralon console at the start of each run (one request to the SCAN_WINDOW_URL written in it, with the run's OIDC token), falling back to the window written beside it.

And the scan reports to two Ferralon endpoints, both written out in the workflow's own with: block. runs-url receives the assessment on runs that analyzed this repository's canonical ref (its default branch unless .github/ferralon.yml names another) so it can be read in the Ferralon console; ingest-url receives the repository, commit and advisory id on every run, and is the channel that signals an uninstall. Neither carries source file contents. Set FERRALON_LINK_TO_CONSOLE to false, or delete the line, to switch all three off.

This file removes itself when the Ferralon App is uninstalled; deleting it manually is also safe — the refs/tegron/state ref cleans itself up either way.

Committed by the Ferralon install provisioner.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants