Add SECURITY.md

[JamieSlome]

Hey there!

I belong to an open source security research community, and a member (@xiaofen9) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

[guybedford]

Per the MIT license, code is provided "AS IS".

No guarantees or commitments are made with respect to maintenance including security maintenance.

[guybedford]

(Specifically, this project was sunsetted over a year ago - https://jspm.org/jspm-dev-release#sunsetting-the-cli)

[JamieSlome]

@guybedford - no worries, completely understand and respect this.

I will leave the report URL just for your reference if you want to glance at it, but no expectation on our part: https://huntr.dev/bounties/9b5ea773-4dca-4e2e-ad62-c9ed80290826/

[guybedford]

I'm not interested in signing into services which profit off the free labour of maintainers without consideration for active maintenance status or security properties.

Security escalation vulnerabilities are only possible in the context of a secure primitive being offered by a software supplier. The JSPM CDN security is a guarantee of the project. A 5 year old CLI that is not active or maintained that never promised any form of sandboxing against unwanted inputs isn't. This is highly common in the OSS ecosystem, and is simply the wrong focus and profiteering.

[JamieSlome]

@guybedford - thoroughly respect your position, and we absolutely do not require maintainers to sign-up to view the contents of reports. We can provide the contents via a magic URL, which grants full maintainer-like capabilities on our platform, and authorization to view reports for the repository in question.

With regards to profiteering and how we work with maintainers, we recognize the time and effort of maintainers as extremely valuable, and so reward bounties to maintainers on any/every report that they have fixed.

Our process of understanding when a repository is open to security contributions is certainly something we know we would like to work on and improve, and so your feedback is extremely appreciated here too.

Ultimately, respect your position 👍

[guybedford]

@JamieSlome when I clicked the report link you sent it says it's not public. Paying maintainers to fix security issues is a much better model, and leading with that would certainly get a better reception I'm sure. Also explain the issue and ask the maintainer if it truly is an escalation based on the root semantics of the security model in play, we work in terms of real details. I understand realising many issues are security theatre over real escalations goes against the business model, but do think systematically please!

[JamieSlome]

@guybedford - it is not currently public, however, you can view it if you sign-up, and have repository write permissions, or we can provide you with the magic URL that I mentioned. We are constantly trying to learn from OSS maintainers, and so cannot claim that our model is perfect today, but rest assured, we are here to learn and listen.

Only working with maintainers on issues that they care about, and problems they see as meaningful is something that we as well want to encourage and achieve.