OSS Checklist

[hughsaunders]

Checklist for New Public CyberArk GitHub Repositories

This document defines the requirements needed to convert an existing private or external project to a public project in the CyberArk GitHub org. In addition, see the Optional section for optional requirements that may or may not apply to your project at current but should be taken into consideration based on project maturity.

Once you have reviewed your project to ensure it meets the requirements below, create a new topic in our CyberArk employee area in Discourse to request making the repo public.

Open-sourcing checklist

• [x] README.md file must be provided, and it should include:
  • [x] Description of the project and its intended use.
  • [x] Project requirements; in particular which versions of our software and tools you have validated that the project supports.
  • [x] The state of the project should be clear. Is this a proof of concept, or a new early-stage product? Is the project still subject to breaking changes?
  • Conjur defines Certification Level based on the Community / Trusted / Certified hierarchy from CyberArk Marketplace, and you may also find these useful for your project.
    • For a Conjur-related project, during your review R&D will work with you to determine the Certification Level of the project. Once it's been determined, a badge must be added to your project README with the correct level:
    • 
    • 
    • 
• [x] Repository includes a link back to the entry-point page for CyberArk open source (https://github.com/cyberark/) so community members visiting the project can see other projects we offer.
• [x] CONTRIBUTING.md should be included.
  • Feel free to use the CONTRIBUTING template as a starting point.
• [x] License is present. Some acceptable licenses include:
  • Apache 2.0 (template) - preferred.
  • MIT (template) - lighter-weight license, okay for demos.
  • If you are unsure which license is appropriate, ask when you submit your request.
• [x] Project maintainers are documented. Maintainers monitor the repo to apply security updates to dependencies and respond to issues or PRs.
  • Maintainers can be listed in a CODEOWNERS file.

• [x] The project must be scanned with gitleaks or git-secrets.

  • Run the full history scan to check that there are no credentials previously pushed in the history.

    Command: gitleaks --repo-path .

• [x] When possible, written content should be reviewed by others, including technical writers.
• [x] The project must be reviewed to ensure no sensitive data has been written to logs or anywhere else.

[Optional]

This document was drafted to define CyberArk open source project standards, but there are some additional requirements that may be appropriate based on the project's maturity. For example, generally available enterprise products typically require a comprehensive security review, automated test suite, official documentation, automated vulnerability and security scans, etc. Individual departments within R&D can provide more details about the specific standards required by their product suites.

[jtuttle]

@hughsaunders Approved to go public.