Overview

This PR updates fossa test to reference an unutilized key in the CLI API response.

Paired with https://github.com/fossas/FOSSA/pull/15973, this change will dynamically print the severity in the fossa test "issue identified" message. In the case that the output is still null (on older instances), "A vulnerability was identified in x" will be shown.

This aligns with the AC in the ticket, though I've removed the hard-coded "Critical vulnerability" reference to avoid confusion.

Acceptance criteria

FOSSA CLI users can now get more accurate information about their projects at a glance when running fossa test.

The fallback also works, on older FOSSA instances

Testing plan

I tested this by compiling the CLI and using the binary on a local project that contained dummy vulnerabilities. Testing was admittedly convoluted, but a reviewer could probably point their local instance to the vulns database and checkout the FOSSA branch from the above PR.

From there, run the CLI from the action and test against a project with vulnerability issues of varying severity.

The output should report the severity of each issue in the identification message.

To confirm the fallback, you can run fossa test on a project in CORE, or a different branch. You should see the fallback message.

Risks

Severity Output Change

I think this has little risk. There's a fallback that also makes the default fossa test message less alarming.

Integration Test Update

This PR also introduces a fix for a failing test by changing the nix channel from unstable to the latest stable version. After some testing, it seems like the unstable channel has an issue with jdk8. I'm not sure if this is transient. This was causing two integration tests to fail. Stable is updated every six months, so I think this may come with some risk.

References

ANE-1892
https://teamfossa.slack.com/archives/C043EM3L96Z/p1752593818823499

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.