Create SECURITY.md

[Willmish]

Pull Request

Issue Number: #415

Summary

Adds security.md file, explaining the security policy for the project.

Checklist

• Local Tests Passing?
• CICD and Pipeline Tests Passing?
• Added any new Tests?
• Documentation Updates Made?
• Are there any API Changes? If yes, please describe below.
• This is not a breaking change. If it is, please describe it below.

Are there API Changes?

N/A

Is this a breaking change?

No

Please follow
GitHub's suggested syntax
to link Pull Requests to Issues via keywords

This PR Closes #415

[Willmish]

Also - we can consider adding an alternative security reporting method (built in gh feature):

for a repo: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository
for an organisation: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-an-organization

example project using this feature: https://github.com/electron/electron/blob/main/SECURITY.md

I would suggest this does not replace the method for contact via an email address, but be an alternative

[Sophietn]

Hey @Willmish
The issue description 'applicable criteria for the Open SSF Best Practice Badge' is needed for the Graduation acceptance criteria
Can we add in how we are doing against that badge criteria?
I think this is the link
https://www.bestpractices.dev/en/criteria

[Willmish]

@Sophietn sure, took a while but added a review of it all, with notes that potentially need addressing at the end, please review @vaughanknight .

According to these criteria, the project deifnitely falls under "Passing" (covering all the points which the project MUST follow)

Basics:

basic proj website content

• Describe what the project does - ✅ in README
• Provide info how to obtain/provide feedback and contribute - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/CONTRIBUTING.md#code-contribution-steps
• Explain contribution process - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/CONTRIBUTING.md#collaborating-with-the-opensource-working-group

FLOSS license

• must be released as FLOSS - ✅ MIT License https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/LICENSE
• must post the license - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/LICENSE
• also approved by OSI - ✅ https://opensource.org/license/MIT/

Documentation

• provides basic documentation - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/tree/dev/docs
• provides documentation for external interface - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/docs/carbon-aware-webapi.md

Other

• project site, downloads etc must support HTTPS with TLS - ✅ using GitHub to host which supports this https://github.com/Green-Software-Foundation/carbon-aware-sdk/
• have mechanism for discussion - ✅ github issues https://github.com/Green-Software-Foundation/carbon-aware-sdk/issues
• project must be maintained - ✅ actively maintaned by GSF and its members

Change control

Public VCS repo

• readable public VCS repo - ✅ yes, Github https://github.com/Green-Software-Foundation/carbon-aware-sdk/
• track changes - ✅ yes, Git https://github.com/Green-Software-Foundation/carbon-aware-sdk/commits/dev/
• interim versions between releases available for review - ✅ yes, interim versions actively developed and availble on the dev branch https://github.com/Green-Software-Foundation/carbon-aware-sdk

Unique versioning numbering

• unique indentifier for each release - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/releases

Release notes

• human readable release notes for each release (not git log) - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/releases
• address each publicly known vulnerability - ✅ N/A, no vulnerability reported yet

Reporting

Bug reporting process

• process to submit bugs - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/issues/new/choose
• must acknowledge bugs (reply) submitted between 2-12 months - ✅ each bug has at least an acknowledgement or was opened by a maintainer (so acknowledged by a maintainer): https://github.com/Green-Software-Foundation/carbon-aware-sdk/issues?q=is%3Aopen+is%3Aissue+label%3Abug
• publicly available archive for reports and responses - ✅ github issues: https://github.com/Green-Software-Foundation/carbon-aware-sdk/issues?q=is%3Aopen+is%3Aissue+label%3Abug

Vulnerability report process

• have a vulnerability report process - ✅ Added in this PR: Create SECURITY.md #464
• Private vulnerability if supported must include info how to send - ✅ N/A (allowed) - no private vulnerability reporting set up but proposed
• initial response time for vulnerability submitted in last 6 months must be <= 14 days - ✅ N/A (allowed) - project run by volunteers, does not provide response time guarantee as stated in SECURITY.md (this pr)

Quality

Working build system

• must provide a working build system - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/docs/carbon-aware-cli.md#build-and-install https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/docs/containerization.md

Automated test suite

• have at least one automated test suite and documentation hwo to run it - ✅ https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/.github/workflows/1-pr.yaml as automated CI during PRs

New functionaility testing

• formal/informal policy for adding tests for new features - ✅ PR template requires stating if a breaking feature added, maintainers ensure tests are in place: https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/.github/pull_request_template.md
• evidence of policy being adhered to - ✅ on release code cov increase (new code added did not decrease test coverage): Release 1.2 #437 (comment)

Warning flags

• compiler wawrning flags or linter tools for code quality/errors - ✅ CodeQL analysis in automated CI : https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/.github/workflows/1-pr.yaml#L82
• address warnings from these tools - ✅ blocking PRs on fail

Security

Secure development knowledge

• at least one primary developer who knows how to design secure software - ✅ @vaughanknight is at least one of them :)
• at least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them - ✅ @vaughanknight is at least one of them :)

Use basic good cryptographic practices

• https://www.bestpractices.dev/en/criteria/0#0.crypto_published - ✅ uses HTTPS for WebAPI, N/A for CLI
• https://www.bestpractices.dev/en/criteria/0#0.crypto_floss - ✅ uses dotnet 6.0 implementations
• https://www.bestpractices.dev/en/criteria/0#0.crypto_keylength - ✅ uses dotnet 6.0 implementations
• https://www.bestpractices.dev/en/criteria/0#0.crypto_working - ✅ uses dotnet 6.0 implementations
• https://www.bestpractices.dev/en/criteria/0#0.crypto_password_storage - ✅ ⚠️ uses dotnet 6.0 implementations, but API key storage needs verification
• https://www.bestpractices.dev/en/criteria/0#0.crypto_random - ✅ uses dotnet 6.0 implementatons for HTTPS

Secured delivery against man-in-the-middle (MITM) attacks

• delivery mechanisms that counters MITM - ✅ uses HTTPS
• cyrptographic hash NOT retrived over HTTP - ✅ ues HTTPS

Publicly known vulnerabilities fixed

• no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 day - ✅ no such vulnerabilities

Other security issues

• public repo doesnt leak private credential - ✅ does not do that

Analysis

Static code analysis

• at least one FLOSS static code analysis tool - ✅ uses CodeQL https://codeql.github.com/ - https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/.github/workflows/1-pr.yaml#L82
• All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed - ✅ ⚠️ confirmed medium vulnerabilities exist but not addressed as location sharing of carbon emissions is one of the main purposes of CA SDK, code needs to be annotated to ignore this: Update documentation of secureness (security.md) #415 (comment)

Dynamic code analysis

• All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. - ✅ N/A (allowed, no DYnamic code analysis in place).

@Willmish notes:

• Reading through these requirements, it might be necessary to re-enable codecov for future releases so we can always verify new features added also come with full test suites (this is true for latest release)
• to verify : https://www.bestpractices.dev/en/criteria/0#0.crypto_password_storage how API keys are stored during configuration
• see :

confirmed medium vulnerabilities exist but not addressed as location sharing of carbon emissions is one of the main purposes of CA SDK, code needs to be annotated to ignore this: #415 (comment)

[danuw]

approved

[Sophietn]

Hey @Willmish - thanks so much for checking us against the criteria for the Open SSF Best Practice Badge. Great we're passing! This review of yours will get lost if it only remains on this PR. Can we copy it onto the security.md please?