#Osquery repositories install#
#Osquery repositories update#
#Osquery repositories software#
#Osquery repositories code#

Screenshot from README.md on Fleet repository showing the OpenSSF best practices badge as passing. Automated PRs run for our go and npm dependencies, not just GitHub actions (as described in dependabot.yml). That way, Scorecards knows we are using Dependabot, but in reality, most of the value comes from enabling Dependabot from GitHub security.

#Osquery repositories update#

We now use Dependabot to automatically create PRs when security updates should be applied to dependencies.Īs Scorecards cannot read from “admin” APIs on the GitHub side, we have also created a dependabot.yml to update our GitHub actions. StepSecurity has a great tool to speed that process up! Configured Dependabot In addition, we pinned actions with hashes to ensure we only run the version we’ve picked and never a version with extras 😅.

PRs should be considered “untrusted input.” We have also eliminated Actions that granted access to important secrets from PRs. That way, if one of the Actions was compromised, its access to the repository is limited. We have secured many GitHub Actions/workflows by configuring explicit permissions for jobs.

#Osquery repositories code#

For this reason, we have automated code review approvals applied to those directories, leaving us free to enforce code reviews on the repository in general. One of the challenges this brings when using a monorepo is that areas of the repository are not security-relevant and do not benefit from code reviews. We already were doing code reviews on almost everything, but we were not enforcing it in the repository for the main branch. In our configuration, we allow uploading the data back to OpenSSF, which will be leveraged in the future by a Scorecards badge, and we upload artifacts to GitHub as a SARIF (Static Analysis Results Interchange Format) file.īy doing this, issues found by Scorecards at each execution are uploaded to the Security tab of our GitHub project, allowing us to detect new issues quickly. We started by deploying the Scorecards GitHub Action. If we did, we’d certainly look to OpenSSF Allstar for automation. The main advantage to this, in this case, is that we also do not have to configure dozens of different GitHub repositories. That means that front-end code, back-end code, documentation, and more are stored there, making it harder to set specific policies on the entire repository. What we changedĪt Fleet, we put almost everything we do in the same repository. It now goes from 5.8 to 6.2, and we plan to continue improving it. When we started using Scorecards to measure our own repository, our score hovered around 4.9. You can also run it against packages in npm, PyPI, or RubyGems.

#Osquery repositories install#

You can install Scorecards on Mac ( brew install scorecard) or Linux, create a GitHub token, and run it in less than 3 minutes. Public data is gathered for popular projects and projects opting to submit results. It checks that a repository is maintained, that automation is in place to manage dependencies, that automated tests are in place, that code is reviewed, and more.

OpenSSF built Scorecards so that anyone can run it against a repository. While researching how we could achieve this goal, we noticed that the Open Source Security Foundation ( OpenSSF) published a project that aims to address this issue at scale. Through the process of acquiring the metrics, we would discover things we can improve as well. We felt we could start by providing some metrics and information to those looking at using anything from the Fleet GitHub repository. Security maturity assessments are a complex topic.

#Osquery repositories software#

We want to provide quality software and a method for potential users to assess the maturity of our security. Customers and open source users use it with osquery, another great open source project. This data can also be used to augment any decision making in an automated fashion when new open source dependencies are introduced inside projects or at organizations.Īt Fleet, we do our work in public. The goal of Scorecards is to auto-generate a “security score” for open source projects to help users as they decide the trust, risk, and security posture for their use case. Tales from Fleet security: GitHub configuration and OpenSSF Scorecards