Update README.md

[kburich]

Add security badge that highlights code security compliance and enhances project transparency. The badge automatically updates when a new version is published.

https://secure.software/npm/packages/minimist

[ljharb]

I’ve checked a few of my packages with that site and am underwhelmed - false positives, and already-fixed vulns show up as somehow being worse than no vulns at all (when in fact that’s better).

I think we’ll pass on this one.

[kburich]

Thanks for the response. First of all I got to say I love your work and thank you for your contributions to open source!

Would love to hear more about your experience with the site as I am one of the developers working on it. Could you be a bit more specific about what you didn't like?

Your feedback would be much appreciated and I'm confident that we could fix any issue you encountered on our side pretty promptly.

[ljharb]

https://secure.software/npm/packages/qs has a "high" issue (that almost surely is a false positive) but there's no way to find out what the issue is or how I can fix it
https://secure.software/npm/packages/resolve has 3 resolved CVEs, and a resolved CVE is a much stronger signal for "secure" than no CVEs at all for any software, so why does it have a scary red exclamation point? same with https://secure.software/npm/packages/forms

then there's a package like https://secure.software/npm/packages/aud which is archived and deprecated, so while there's no known CVEs, if one were discovered it probably wouldn't get fixed, so it definitely should not show up as green/safe/secure.

in other words, it appears like this site is "punishing" packages that have ever had vulnerabilities, when in fact the proper security posture is to assume every single package in existence has vulnerabilities, they're just not all known yet - and evidence that maintainers respond to and resolve vulnerabilities means the package is secure, whereas no evidence whatsoever means its security is unknown.

(also, in general, any reported problem should be clickable and take me to a more detailed explanation of the precise problem in this package, not a generic page describing the category of problem)

[kburich]

Thank you for the great feedback. We will thoroughly analyze the feedback and I will get back to you :)

[kburich]

Not sure if you've seen the email I sent you last week but bottom line is that the site is not most appropriate for more advanced triaging of issues. We have another product for that https://www.reversinglabs.com/products/software-supply-chain-security. If you are interested more in advanced triaging of found issues please check out the email I've sent you.

Also it is not our intention to punish packages for past issues (example https://secure.software/npm/packages/@rspack/core/versions/1.2.4). Most of the issues found in the packages you mentioned can be easily fixed. For example the CVEs from https://secure.software/npm/packages/forms/vulnerabilities can be fixed by bumping versions of dependencies qs and async which you have already done on the master branch from what I see.

We do acknowledge that we can make some UX improvements that you pointed out and we are also always looking to refine our threat detection rules. Our community manager Kadi would love to talk to you as well if you are open to a call :)

[ljharb]

@kburich thanks, i did but i've been traveling.

Since all of these packages' dependencies use ^, and non-vulnerable versions of dependencies can be freely updated to without any action in this package, these packages simply aren't vulnerable. I think your product may be lacking an accurate understanding of semver ranges in concert with transitive dependencies.

[kburich]

Yes this has been a point of discussion for us in the past. You are right the non-vulnerable versions of those dependencies CAN be freely updated but don't have to be. Currently we choose to err on the side of caution in this case.

[ljharb]

It’s the responsibility of application consumers to keep their lockfiles updated; it’s not helping anything to imply that maintainers have work they need to do. That’s the whole point of using semver ranges.

[kburich]

Yes I see your point of view and as mentioned we have debated over this before and have a feeling we will be debating over it again soon :). We don't want to create unnecessary noise for maintainers. Our intention is to help you build secure software.