A community-driven collection of open source tools to improve the security of your Google Cloud Platform environments.
Get Started with Forseti Security.
We are continually improving Forseti Security and invite you to submit feature requests and bug reports. If you would like to contribute to our development efforts, please review our contributing guidelines and submit a pull request.
If you would like to contribute to forsetisecurity.org, the website and its content are contained in the forsetisecurity.org-dev branch. Visit its README for instructions on how to make changes.
For information on how this project is managed and governed review our governance guidelines.
Review our community page for ways to engage with the Forseti Community.
Support for the Forseti Security product can be obtained through a few channels:
- Join the Slack Channel and engage in discussions with other users and the Forseti community.
- Ask a question about Forseti and get community support by posting to (discuss@forsetisecurity.org). Posts can receive responses from the community or from engineers on the Forseti team.
- File a GitHub issue. Issues are typically reviewed and triaged within 24 - 48 hours.
Product releases will occur on a quarterly schedule. An out of band patch release may occur but only for a critical defect or security issue. The team will support patching critical defects or security issues in the current release and in the 2 previous quarterly releases only. If a defect is found in a release beyond current - 2 customers are expected to upgrade to a current supported version of the product.
The triage process is a multi-step process that is collaboratively performed by the core project team and our issue bot. Triaging typically should occur within 1 - 2 business days, but may take longer, if the project team is not around. The purpose of triaging is to clearly understand the request and determine the next steps for what will happen with your issue. It's straightforward to understand whether or not your issue is triaged: if the issue contains the triaged :yes label this indiacts the issue has been reviewed and classified by the project team. In the case of a bug the a team member may request more details or information in order to better understand the problem, help determine prioritization or aid in reproducing the issue. We close issues for the following reasons:
| Reason | Label |
|---|---|
| The issue is obsolete or already fixed. | N/A |
| We didn't get the information we needed within 7 days. | issue-review: need-more-information |
| Given the information we have we can't reproduce the issue or do not feel the issue necessitates a fix. | issue-review: closed won't fix |
| There has been activity on the issue for a significant period of time. | stale |
In addition to milestones representing our iterations for our product releases we add additional labels that have special meaning:
BacklogIssue to be considered at some point in the future1 - PlanningIssues being considered for one of the next 3 iterations. The issue is on the short list to be assigned to a concrete iteration.2 - ReadyIssue assigned and scheduled for a specific target milestone release3 - Work in progressIssue is assigned to engineer and is actively working on the issue for targeted milestone release
The team and community encourages pull requests to fix issues or improve the product. Pull requests are typically reviewed within 48 hours of submission. If pull requests become inactive they will be automatically closed, but can be quickly and easily re-opened. Please review the project’s contributing guidelines before submitting a pull request.