feat: add experimental support for updating config files

[G-Rath]

This is an attempt to port the --update-config-ignores feature from osv-detector, which has been useful especially for onboarding new codebases and updating existing ones after patching has been done to prune out old entries.

Currently this does not preserve comments or specific formatting, but I'm hopeful those are things we can improve on future especially if this proves to be a popular flag

[codecov-commenter]

Codecov Report

❌ Patch coverage is 87.59124% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.38%. Comparing base (bd87118) to head (be56aee).
⚠️ Report is 15 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/osvscanner/configs.go	85.91%	5 Missing and 5 partials ⚠️
pkg/osvscanner/osvscanner.go	78.94%	2 Missing and 2 partials ⚠️
internal/config/config.go	94.11%	1 Missing and 1 partial ⚠️
cmd/osv-scanner/internal/helper/flags.go	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2534      +/-   ##
==========================================
+ Coverage   79.30%   79.38%   +0.07%     
==========================================
  Files         122      123       +1     
  Lines        8279     8393     +114     
==========================================
+ Hits         6566     6663      +97     
- Misses       1333     1340       +7     
- Partials      380      390      +10     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[another-rex]

Being able to automatically remove not found vulnerabilities from the config files seem quite useful.

However I'm not sure how much we want to encourage people to automatically add all their vulns to the ignore file. At least we should separate the two functionalities, maybe by making UpdateConfigIgnores not a boolean flag

[another-rex]

Should we add a comment/reason saying this is automatically added by the new flag?

[G-Rath]

at this point I'm leaning to not doing that just for simplicity, and I'd rather add it later to see how we feel - I'll explore this once I'm done with the core implementation

[G-Rath]

However I'm not sure how much we want to encourage people to automatically add all their vulns to the ignore file

I originally felt against this kind of thing too, similar to also having tools like this exit as an error if there were unused ignores, but I've found in practice at least in an agency company kind of context it can really help reduce the friction - I'm able to tell other developers who are less familiar with this space to just add "xyz flag" rather than needing to try explain how to write ignores (which they can still learn about because they see the diff + it helps keep the actual order and format consistent), and when onboarding apps from other vendors we can get the security pipelines setup faster by initially ignoring all existing vulns and then go back to triage.

With osv-detector prior to this flag I was having to run this jq query:

osv-detector --json . | jq -r  '[.results[].packages | map("- " + .vulnerabilities[].id)] | flatten | unique | sort | .[]'

which has no hope of preserving any other config content including other properties and comments (the latter of which are not being preserved "yet")

At least we should separate the two functionalities, maybe by making UpdateConfigIgnores not a boolean flag

I really like this idea, because then we could also later introduce an "interactive" mode which could let you set reasons and "until" dates.

---

One side thing to consider with this is if we do the updating before or after our filtering - currently I have it being done before which means the tool always presents "no vulns found" and with a non-zero exit code; currently osv-detector does it the other way around, presenting everything as if it wasn't going to add ignores, and just adds a "ignored vulns" message at the end of its output.

Since this is being added an experimental flag we don't need to decide right now, but something to think about - I can explore this more once we've gotten the rest of the implementation settled, since it should just be a case of moving a function call to see the difference 🤷

[G-Rath]

@another-rex @cuixq I think this one should be good to go 🤞