Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: add a security policy document #504

Merged
merged 1 commit into from
Sep 25, 2024
Merged

docs: add a security policy document #504

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Security policy

## Supported versions

Security updates will be released for all major versions that have had releases in the last year,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify "all major versions" -- given we only have 1.x.y, I guess this means just one security update?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, plus the ones that Juju needs. The "only for majors" is where we currently landed for ops, so I re-used that here.

We could have a table here listing versions like some projects do, but that seems a pain to maintain. LXD has rules for monthly and LTS releases - we could copy that but have Juju instead of LTS?

(The "what qualifies" section in the LXD one I think would be good here too, but probably after the current modelling work is done).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what you have now is fine -- I just wanted to clarify the intent. Could add a little parenthetical to clarify for others like "(1.x versions)" if you want.

and for all versions of Pebble that are bundled with [Juju](https://github.com/juju/juju)
releases that [receive security updates](https://juju.is/docs/juju/roadmap).

## Reporting a vulnerability

Please provide a description of the issue, the steps you took to
create the issue, affected versions, and, if known, mitigations for
the issue.

The easiest way to report a security issue is through
[GitHub's security advisory for this project](https://github.com/canonical/pebble/security/advisories/new). See
[Privately reporting a security
vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability)
for instructions on reporting using GitHub's security advisory feature.

The Pebble GitHub admins will be notified of the issue and will work with you
to determine whether the issue qualifies as a security issue and, if so, in
which component. We will then figure out a fix, get a CVE
assigned, and coordinate the release of the fix.

You may also send email to [email protected]. Email may optionally be
encrypted to OpenPGP key
[`4072 60F7 616E CE4D 9D12 4627 98E9 740D C345 39E0`](https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x407260f7616ece4d9d12462798e9740dc34539e0)

If you have a deadline for public disclosure, please let us know.
Our vulnerability management team intends to respond within 3 working
days of your report. This project aims to resolve all vulnerabilities
within 90 days.

The [Ubuntu Security disclosure and embargo
policy](https://ubuntu.com/security/disclosure-policy) contains more
information about what you can expect when you contact us, and what we
expect from you.
Loading