I went through and created https://bestpractices.coreinfrastructure.org/en/projects/3125

It's worth having a couple more folks edit that. Especially looking through the silver or gold levels. There's a lot of random bits todo.

Thanks for starting this! I just reviewed the answers provided so far.

• Under "unique version numbering" there's a typo: semvar, but you meant SemVer
• Vulnerability report process, responsiveness: I think we do have one example within the last six months, https://nvd.nist.gov/vuln/detail/CVE-2019-3567 in which I believe the initial response to vulnerability reporting was <14 days? May 22nd was the disclosure by Facebook, but we don't know when it was disclosed to them.
• Vulnerability disclosures: we have a place on GitHub now, to list these. For future use. It's a new feature. https://github.com/osquery/osquery/security/advisories
• Working build system, FLOSS tools: the only caveat here is if building for Windows, we are using the MSVC compiler, which is not FLOSS. Code signing on macOS and Windows is not possible with FLOSS either right? Interpreting the question more favorably, yes, it's all buildable on Linux with FLOSS-only tools.
• Basic good cryptographic practices: typo here ("cryptograph"). We can specifically say that we use OpenSSL, HTTPS (TLS, not SSL) for data in transit, and certificate-based server authentication (also can be added detail for the MITM question)

For addressing the static analysis category, I think we are "Unmet" for these currently, but Alessandro opened osquery/osquery#5728 and osquery/osquery#5727

For dynamic analysis, we've recently opened a PR for Clang sanitizers, which would fulfill the requirement: osquery/osquery#5628

Regarding the silver badge criteria:

• I think we can claim a "bus factor" of higher than 2 on the basis of there are more than 2 members of the TSC.
• We should review the "moving parts" document and indicate anything on there where 1 person could disappear with sole access to something. Signing keys?
• Roadmap: unmet, but I assume this is a high priority up next
• Quickstart guide: doesn't this suffice? https://osquery.readthedocs.io/en/latest/#getting-started
• Documentation consistent with project: we could point out that ReadTheDocs is auto-generated from commits to the repo (docs subdirectory), as are the tables on the schema page on the osquery website (table specs directory?). I think we can make a reasonable claim that the documentation is current, and a reasonable promise to keep it current.
• Must link to achievements within 48 hours: sure man, I doubt anyone will waste time updating the badge if we reach Silver or Gold.
• Accessibility: being that osquery generates only textual output and none of it relies on color, I think we can give ourselves an easy 'Met', here.
• Internationalization: I think this will have to be a milestone with multiple issues attached, like Mis-encoded UTF-8 characters in differential log results osquery#5288 , osqueryi output JSON data format error if table data has chinese world osquery#4737 , osquery appears to ignore files with names that contain multibyte characters over U+00FF on Windows osquery#4150 , Should not use ANSI Windows APIs osquery#2569 , and maybe flags: osquery silently fails to parse flagfile with different encodings on Windows osquery#4753 , and maybe we ought to open a new issue for "internationalizing" any hard-coded strings.

For what it's worth, we're tackling I8N issues right now for Python Software Foundation on a different project. Maybe what we learned there will be useful.

• Previous versions: clearly we don't have the bandwidth to support a 3.x branch. Isn't the upgrade path from 3.x to 4.0 just "install new osquery"? Were there any gotchas to document? We can promise to provide easy upgrade paths in the future. That would fulfill this requirement.
• Vulnerability report process: we can cite the SECURITY policy, and then add CVE-2019-3567 with credit to Facebook (?) to the advisories section of GitHub https://github.com/osquery/osquery/security/advisories and point to that
• Coding styles: Introduce clang-tidy support osquery#5729 and document code guidelines osquery#5593
• Working build system: with CMake I believe we are "Met" for all of these, but can @alessandrogario confirm?
• Installation system: yes, with Chocolatey, Homebrew, MSI package, etc. But allowing a configurable install location might be N/A because we can't have the user putting osquery in a world-writable directory.
• External dependencies: they're talking about a dependency manifest, but there is no C++ package manager so I suggest marking N/A or pointing to how we third-party dependencies are enumerable as Git submodules now.
• Dependency vulnerability checking: n/a, we have to do this manually with C++ wouldn't we?
• Easy to update dependencies: I think we've done the best you can do in C++
• Avoid using deprecated APIs where FLOSS alternatives exist: unless they have an example of this, "Met"
• Automated test suite: Met, we're doing that now with the CI system
• Regression tests: Unmet, there has been no effort to do that yet
• Test coverage: we already use gtest; what is our gcov currently?
• "Must have policy to add tests with new functionality" — we can link to our PR template that makes this the policy already https://github.com/osquery/osquery/blob/master/.github/PULL_REQUEST_TEMPLATE.md
• Secure design principles: we should open a new issue "document security design of osquery"
• Cryptographic principles: algorithm support: we use OpenSSL which should continue to provide algorithmic alternatives and best-practices for transport encryption, and all of that should be transparent to osquery. The link to our multiple supported TLS ciphers: https://github.com/osquery/osquery/blob/e6fe15eb49660725e65dba1549932ed96e0a8c6e/osquery/remote/transports/tls.h#L24
• Storing authentication credentials: n/a or maybe "Met" if referring to the credentials to our project's repos, CI, ReadTheDocs account etc. But someone who understands client enrollment and the handling of the TLS client secret key should weigh in.
• No use of insecure protocols: Met. Again, see https://github.com/osquery/osquery/blob/e6fe15eb49660725e65dba1549932ed96e0a8c6e/osquery/remote/transports/tls.h#L29 and https://github.com/osquery/osquery/blob/master/osquery/remote/transports/tls.cpp#L104
• "Must perform certificate verification before sending HTTP headers" yea someone will have to look carefully to verify that
• Cryptographically sign stable releases: we should be "Met" already for this
• Inputs from untrusted sources: we could arguably mark n/a for this, as osquery doesn't handle input from untrusted sources except as through a system API
• Compile-time hardening mechanisms: we opt into them, see /cmake/flags.cmake
• "Provide an assurance case" this would be related to documenting the security design of osquery, mentioned above.
• Static/dynamic analysis: these are repeats of the "passing" level criteria, we just have to do them.

Regarding the gold badge criteria:

• "at least two unassociated significant contributors." Met, just link to https://github.com/osquery/osquery/graphs/contributors and https://github.com/osquery/osquery/blob/master/CODEOWNERS
• "a copyright statement in each source file": Met
• "a license statement in each source file.": Met
• "identify small tasks": Met, with the use of https://github.com/osquery/osquery/labels/easy and https://github.com/osquery/osquery/labels/good-first-issue
• "require two-factor authentication (2FA) for developers for changing a central repository" and no SMS 2FA: the GitHub admin for the osquery organization has to turn this setting on
• "code review standards": Unmet, right?
• "two person review": Met, for sure
• "Reproducible builds": in progress with Provide a custom toolchain for osquery 4.x osquery#5609
• "Automated test suite": Met, link to instructions on running the tests https://osquery.readthedocs.io/en/latest/development/building/#testing
• Test coverage: see comment on Silver criteria
• Cryptographic practices: Met, see comment on Silver criteria
• "Must have a security review": Trail of Bits is available 😏
• Hardening mechanisms: Met, see comment on Silver criteria
• Dynamic analysis: see comment on Silver criteria
• "Include many run-time assertions": could this be interpreted to be "Met" with the use of Clang ASAN? The sanitizer, combined with tests, is checking a lot of assertions in a sense.

About the build system questions: the first three are all met now, while the last will be met when we merge the third-party-submodules PR (with the custom toolchain).

We have applied for CII, and displayed the badge. osquery/osquery#5744

What remains is incorporating the rest of the comments on this issue here into the answers on CII, and/or generating new issues for individual goals.

Ok, I've marked off the silver badge requirement for having a Security Assurance doc 👍🏻

Internationalization would be the biggest remaining obstacle to having the Silver Badge.