+ Step {{ step + 1 }}/{{ steps.length + 1 }} - + Choose YAML file template + {{ currentStep?.label }} + Preview & Download +
++ Review your generated YAML file before downloading. You can copy the content or download it as + a file. +
+ ++ Add the YAML file as security.yaml in your + repository root and commit to enable security assessments. +
+{{ yaml }}
+ + YAML security file provides a standardised way to document, assess, and share a + project's security practices, ensuring consistency and alignment with the specification + across repositories. + + Learn more + +
++ Repository owner or admin. You'll need write permissions to upload the generated file to + your GitHub repository. +
++ YAML security file specifications are optional, and we don't run strict + validation on them, but your project will still benefit from documenting + as many as possible. +
++ Please select the YAML template file that better aligns with your project repository and + security requirements. +
+ ++ {{ option.description }} +
+Project details
+Repositories
++ Details about your project repository and contribution policies. +
+Repository #{{ index + 1 }}
+ +Project details
+Vulnerability reporting
++ Configure how security vulnerabilities can be reported for your project. +
+Reports accepted
++ Your project accepts vulnerability reports from security researchers +
+Bug bounty available
++ Your project offers rewards for discovering and reporting security vulnerabilities +
+Best practice recommendation
++ Even if you don't offer a bug bounty program, accepting vulnerability reports shows that + your project takes security seriously and provides a clear channel for responsible + disclosure. +
++ Basic project information and administrator contacts. +
++ People who have administrative access to the project. At least one administrator is + required. +
++ Administrator #{{ index + 1 }} +
+Repository details
+License information
++ Specify the license under which your project is distributed. This information helps users + understand how they can use, modify, and distribute your code. +
+URL to the full text of your project's license
++ SPDX license identifier (e.g., MIT, Apache-2.0, GPL-3.0, BSD-3-Clause) +
+Common license examples
++ MIT: + Permissive license with minimal restrictions +
++ Apache-2.0: + Permissive license with patent protection +
++ GPL-3.0: + Copyleft license requiring derivative works to be open source +
++ BSD-3-Clause: + Permissive license similar to MIT with additional clause +
+Repository details
+Core team members
++ Active contributors and maintainers of the project. These are the people responsible for the + ongoing development and maintenance of the project. +
+Team member #{{ index + 1 }}
+Repository details
+Security self-assessment
++ Provide additional context about your project's security posture and any self-assessment + comments. +
+Self-assessment comment
++ Describe your project's security practices, any security reviews conducted, known + limitation, or other relevant security information. +
+Self-assessment tips
++ Details about your project repository and contribution policies. +
+Accepts change requests
+Accepts automated change requests
++ Basic information about your project that will appear at the top of the YAML file. +
++ The main URL where your project can be found (typically GitHub repository URL) +
++ Repository where the YAML security file is hosted +
+Repository details
+License information
++ Specify the license under which your project is distributed. This information helps users + understand how they can use, modify, and distribute your code. +
++ URL to the full text of your project's license +
++ SPDX license identifier (e.g., MIT, Apache-2.0, GPL-3.0, BSD-3-Clause) +
+Common license examples
++ MIT: + Permissive license with minimal restrictions +
++ Apache-2.0: + Permissive license with patent protection +
++ GPL-3.0: + + Copyleft license requiring derivative works to be open source +
++ BSD-3-Clause: + + Permissive license similar to MIT with additional clause +
+Repository details
+Security self-assessment
++ Provide additional context about your project's security posture and any self-assessment + comments. +
++ Describe your project's security practices, any security reviews conducted, known + limitation, or other relevant security information. +
+Self-assessment tips
+Repository details
+Core team members
++ Active contributors and maintainers of the project. These are the people responsible for the + ongoing development and maintenance of the project. +
+Team member #{{ index + 1 }}
++ Details about your project repository and contribution policies. +
+Accepts change requests
+Accepts automated change requests
+Project details
+Administrators
++ People who have administrative access to the project. +
+Administrator #{{ index + 1 }}
+Project details
++ Project resources regarding set up, policies, and processes that support proper usage and + contribution. +
++ Beginner-friendly setup or installation guide +
++ Full project documentation or reference manual +
++ Rules on behavior and community participation +
++ Releases planning, approval, and publishing processes +
++ Project support guidelines and assistance +
++ Instructions for verifying signed releases or artifacts +
+Project details
+Repositories
++ List all the project's related repositories to ensure that security policies, reporting + processes, and documentation are applied consistently across the entire project. +
+Repository #{{ index + 1 }}
+ +Project details
+Steward
++ Information about the individual responsible for overseeing the project, ensuring its proper + management. +
++ Project’s primary steward or maintainer identifier (URL or contact reference) +
++ Notes about the steward’s role or responsibilities +
+Project details
+Vulnerability reporting
++ Configure how security vulnerabilities can be reported for your project. +
+Reports accepted
++ Your project accepts vulnerability reports from security researchers +
+Bug bounty available
++ Your project offers rewards for discovering and reporting security vulnerabilities +
+Best practice recommendation
++ Even if you don't offer a bug bounty program, accepting vulnerability reports shows that + your project takes security seriously and provides a clear channel for responsible + disclosure. +
+Contact
++ Contact person responsible for receiving and managing security vulnerability reports +
+Project's security policy (e.g. SECURITY.md)
+Types of issues acceptable for reports
+Types of issues non-acceptable for reports
++ Public PGP key used for secure vulnerability disclosures +
+Notes or clarifications about the reporting process
++ Basic project information and online references on how it is supported and developed over + time. +
+Project or repository main website
+Project sponsorship website
++ Website containing future plans, milestones, or feature goals. +
+Repository details
+Documentation
++ Repository resources regarding set up, policies, and processes that support proper usage and + contribution. +
++ How new contributors can participate, submit changes, or follow project workflows. +
++ Rules or processes for reviewing contributions, such as code reviews, approvals, or + quality checks. +
++ Security practices, disclosure process, and reporting guidelines. +
++ How decisions are made, who has authority in the project, and how leadership or roles are + structured. +
++ How external dependencies are tracked, updated, and audited for security or stability. +
+Repository details
+Core team members
++ Active contributors and maintainers of the project. These are the people responsible for the + ongoing development and maintenance of the project. +
+Team member #{{ index + 1 }}
+Repository details
+Release information
++ Provide key details about the repository release process so contributors can verify, + understand, and safely use published versions. +
++ Reference to the changelog location or template used to track release changes. +
+Automated pipeline
+Attestations
++ Evidence or metadata (such as signed statements or provenance files) that verify how and + when a release was built. +
+Attestation #{{ index + 1 }}
+Distribution points
++ Official sources where releases can be downloaded or accessed, such as package + registries, artifact repositories, or release pages. +
+Distribution point #{{ index + 1 }}
+Release license
++ Specify the license under which your repository is distributed. This information helps + users understand how they can use, modify, and distribute your code. +
++ URL to the full text of your project's license +
++ SPDX license identifier (e.g., MIT, Apache-2.0, GPL-3.0, BSD-3-Clause) +
+Common license examples
++ MIT: Permissive license with minimal restrictions +
++ Apache-2.0: Permissive license with patent + protection +
++ GPL-3.0: Copyleft license requiring derivative + works to be open source +
++ BSD-3-Clause: Permissive license similar to MIT + with additional clause +
+Repository details
+Security champions
++ Contributors or maintainers who take responsibility for promoting secure development + practices, assisting with vulnerability triage, and serving as a point of contact for + security-related matters in the repository. +
+Security champion #{{ index + 1 }}
+Repository details
+Security tools
++ Tools used to assess, monitor, or enforce security within the repository. This includes + static analysis, dependency scanning, vulnerability detection, and other automated or manual + security solutions. +
+Security tool #{{ index + 1 }}
+Repository details
+Security assessments
++ Provide additional context about your repository security posture, such as self-assessment + and third-party assessments. +
+Self-assessment
++ Describe your repository security practices, any security reviews conducted, known + limitation, or other relevant security information. +
+Self-assessment tips
+Third-party assessment
++ Provide information about independent security audits, code reviews, or certifications + performed by external parties. +
+Third-party assessment #{{ index + 1 }}
++ Details about your project repository and contribution policies. +
+Rulesets
++ Specific rules, policies, or configurations applied by the tool +
+ +Adhoc results
++ Findings from manual or one-off runs of the tool, typically executed outside of + automated workflows. +
+CI results
++ Security findings generated automatically during continuous integration builds or pull + request checks. +
+Release results
++ Results from checks performed as part of the release process, validating security + before publishing a new version. +
+Integration
++ How the security tool is incorporated into the project's workflow. +
++ Basic information about your project that will appear at the top of the YAML file. +
++ The main URL where your project can be found (typically GitHub repository URL) +
+