Merge pull request #161 from grendel-consulting/community

.github/CODEOWNERS

@@ -0,0 +1,8 @@
+# You should specify the repos maintainers here, per the instructions in:
+#   https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
+#
+# You may choose to include the repo's primary maintainer on every pull request
+
+@ramirezj
+
+# Otherwise use the same syntax as .gitignore to assign per folder, file type or feature below:

.github/CONTRIBUTING.md

@@ -0,0 +1,52 @@
+# Contributing Guidelines
+
+First off, thanks for taking the time to contribute!
+
+We're conducting an experiment here by
+[working in the open](https://visitmy.website/2020/01/25/blogging-working-open/). We're finding
+out what works, and for that other perspectives matter.
+
+## Our Code of Conduct
+
+Our project and everyone participating in it are governed by our
+[Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to
+uphold this code. Please report unacceptable behavior to the project team at
+[abuse@grendel-consulting.com][contact] or through the options to report an abusive
+[issue](https://docs.github.com/en/github/building-a-strong-community/reporting-abuse-or-spam#reporting-an-issue-or-pull-request)
+or
+[comment](https://docs.github.com/en/github/building-a-strong-community/reporting-abuse-or-spam#reporting-a-comment).
+
+## Getting Started
+
+Please start a conversation or raise an issue about the feature or issue you've
+found; that provides us an opportunity to understand what you've spotted, where
+it challenges our approach and where it augments it.
+
+## Your Commits
+
+We request that prospective contributors include themselves in our [Contributors](../CONTRIBUTORS.md)
+within their first pull request, to indicate they have read these guidelines and
+agree to uphold our [Code of Conduct](CODE_OF_CONDUCT.md).
+
+We require that contributors:
+
+- [Sign off their commits](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-commit-signoff-policy-for-your-repository#about-commit-signoffs)
+- [Sign their commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
+
+You can read about the [difference between signing-off and signing](https://medium.com/@MarkEmeis/git-commit-signoff-vs-signing-9f37ee272b14).
+
+## Our Conventions and Styleguides
+
+We practise [scaled trunk-based development](https://trunkbaseddevelopment.com/) with
+[short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/)
+and [continuous integration](https://trunkbaseddevelopment.com/continuous-integration/)
+for everything being worked on by humans. Bots handle the heavy lifting in the
+subsequent pull requests.
+
+We maintain a consistent opinionated style using Linters and Formatters.
+
+Our Code Scanners help spot bugs, issues, and vulnerabilities.
+
+Dependencies are pinned and kept evergreen automagically.
+
+[contact]: mailto:abuse@grendel-consulting.com

.github/DEVELOPER_CERTIFICATE_OF_ORIGIN

@@ -0,0 +1,37 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.

.github/SECURITY.md

@@ -0,0 +1,108 @@
+# Security Policy and Procedures
+
+Our security policies and procedures as a whole are outlined below. Broadly,
+we wish to avoid leaving the ecosystem worse than we found it.
+
+## Supported Versions
+
+Where appropriate, we will indicate which versions of a specific project are supported.
+
+## Reporting a Bug or Vulnerability
+
+We take all security bugs in our projects seriously. Thank you for improving the
+security of them. We appreciate your efforts and responsible disclosure, and will
+make every effort to acknowledge your contributions. At this time, we do not run
+a formal bug bounty programme.
+
+Report security bugs by emailing us at
+[security@grendel-consulting.com][security].
+
+We will acknowledge your email within 72 hours, and will send a more detailed
+response within a further 72 hours indicating the next steps in handling your
+report. After the initial reply to your report, we will endeavor to keep you
+informed of the progress towards a fix and full announcement, and may ask for
+additional information or guidance.
+
+Report security bugs in third-party modules should be to the person or team
+maintaining said module.
+
+## Disclosure Policy
+
+We are advocates of [responsible vulnerability disclosure][disclosure]. If you’ve
+found a vulnerability, we would like to know so we can fix it.
+
+Disclosures should be sent to [security@grendel-consulting.com][security], including:
+
+- Your name and affiliation
+- Sufficient details of the vulnerability to allow it to be understood and
+  reproduced; this would include the website, page or repository where the
+  vulnerability can be observed
+- Optionally, the type of vulnerability and any related [OWASP category][category]
+- Relevant HTTP requests and responses, HTML snippets, screenshots or any other
+  supporting evidence. Redact any personal data before reporting
+- Proof of concept code (if available), or non-destructive exploitation details
+- The impact of the vulnerability
+- Any references or further reading that may be appropriate
+
+Our investigation process is straight-forward. We will work to:
+
+- Confirm the problem and determine the affected versions.
+- Audit code to find any potential similar problems.
+- Prepare fixes for all releases still under maintenance
+
+## Security Checklist and Recommendations
+
+We have baked some baseline security checks into our toolchains, to be reflected
+in this section together with things to watch out for.
+
+### Our Security Toolchain
+
+- GitHub [Advisories](https://github.com/grendel-consulting/steampipe-plugin-kolide/security/advisories)
+- [Renovate](https://renovate.whitesourcesoftware.com/)
+- [StepSecurity](https://www.stepsecurity.io/)
+- [SocketDev](https://socket.dev/)
+
+### Our Security Checklist
+
+- [ ] You MUST encode, escape and validate any inputs
+- [ ] You MUST NOT commit secrets, passwords or keys
+- [ ] You SHOULD pin any new dependencies
+
+### Recommendations
+
+Prospective contributors are encouraged to familiarise themselves, if not already,
+with existing techniques and good practise.
+
+## Providing Feedback
+
+If you have suggestions on how this process could be improved, please submit a
+pull request.
+
+## Versions
+
+All notable changes to this policy should be noted below. We use
+[SemVer](https://semver.org) for versioning, with the following intents:
+
+- We will increment the MAJOR version when we change contact information,
+  encryption keys, or a field in security.txt in a backwards-incompatible manner
+- We will increment the MINOR version when we otherwise change this file or the
+  security.txt in a backwards-compatible manner
+- We will increment the PATCH version for minor typos or similar
+
+### Version History
+
+- 1.0.0 (2024-04-10) - Initial policy and procedures
+
+## Attribution
+
+Thanks to [@trewaters](https://github.com/trewaters) for their thoughts on
+[structuring a SECURITY readme](https://github.com/Trewaters/security-README)
+together with the team behind [security.txt](https://securitytxt.org/)
+
+Based in part on the excellent material in the [standardjs security readme](https://github.com/standard/.github/blob/master/SECURITY.md)
+
+Licensed under [CC BY-SA 4.0 Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)
+
+[security]: mailto:security@grendel-consulting.com
+[disclosure]: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#responsible-or-coordinated-disclosure
+[category]: https://owasp.org/www-project-top-ten/

.github/SUPPORT.md

@@ -0,0 +1,3 @@
+## Support Policy and Guidelines
+
+We're a small team, so the best bet is to email us at `hello@grendel-consulting.com`.

CONTRIBUTORS.md

@@ -0,0 +1,22 @@
+# Contributors
+
+We require prospective contributors to attest to the
+[Developer Certificate of Origin (DCO)](https://developercertificate.org/)
+by including a commit in their first pull release, adding their GitHub username
+to the list of contributors below. Further information is in our
+[Contributing Guidelines](.github/CONTRIBUTING.md)
+
+## Core Maintainers (and Responsibilities)
+
+**Lead Maintainer:** [@ramirezj](https://github.com/ramirezj)
+
+## Individual Contributors
+
+- Your name here?
+
+## Bots (and GitHub Apps)
+
+- [@coderabbitai](https://github.com/apps/coderabbitai)
+- [@step-security-bot](https://github.com/step-security-bot)
+- [@renovate-bot](https://github.com/apps/renovate)
+- [@dependabot](https://github.com/apps/dependabot)