[Automated] Update grype CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to grype CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[claude]

PR Review: Automated grype CLI Options Update

This is a fully automated PR generated by ModularPipelines.OptionsGenerator. The sole change is a timestamp bump in AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-29T03:15:57.4390081Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-05T03:22:51.2019582Z")]

No options classes, command definitions, enums, or service interfaces were modified — the generator ran against the latest installed grype CLI and found the tool's API to be unchanged since the last run (2026-03-29).

Assessment

The change is correct and intentional. The generator is doing exactly what it should: periodically re-scraping the CLI help output and recording a new GeneratedAt timestamp to reflect the check, even when the underlying tool definition hasn't changed.

One Observation Worth Noting

Because this PR contains no substantive diff beyond the timestamp, it adds noise to the PR history without delivering any value. Consider whether the generator workflow should suppress PRs (or skip the commit entirely) when the only diff is a timestamp change. For example:

// Before committing/opening a PR, check whether anything other than
// the AssemblyMetadata timestamp changed. If the only change is the
// GeneratedAt attribute, skip creating the PR.
if (diff.OnlyTimestampChanged())
    return; // nothing to do

This would reduce automation fatigue and keep the PR log meaningful. The current behaviour is harmless, but over time a stream of timestamp-only PRs can desensitise reviewers to automated changes, which is a mild security/quality risk (easy to auto-approve something that actually changed).

Summary

• The change itself is correct and safe to merge.
• No functional impact on generated options or runtime behaviour.
• Optional improvement: suppress PRs when only the GeneratedAt timestamp differs from the previous run.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}