woodpecker

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

If this is your project, please show your badge status on your project page! The badge status looks like this:

Badge level for project 5309 is passing

Here is how to embed it:

You can show your badge status by embedding this in your markdown file:

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/5309/badge)](https://www.bestpractices.dev/projects/5309)

or by embedding this in your HTML:
<a href="https://www.bestpractices.dev/projects/5309"><img src="https://www.bestpractices.dev/projects/5309/badge"></a>

These are the

level criteria. You can also view the

or

level criteria.

Change Control 1/1 ●

Previous versions

Criterion [maintenance_or_update]
Met

Unmet

N/A

?

The project MUST maintain the most often used older versions of the product or provide an upgrade path to newer versions. If the upgrade path is difficult, the project MUST document how to perform the upgrade (e.g., the interfaces that have changed and detailed suggested steps to help upgrade). ^{[maintenance_or_update]}

there are ways we can do security big-fix updates ... and did so in the past: https://github.com/woodpecker-ci/woodpecker/releases

but we normally just bump the version according to semantic versioning and courage people to upgrade. There is always documentation on how to do so in breaking cases: https://woodpecker-ci.org/docs/next/migrations

and mostly deprecation is done in advance to give all admins heads up at least one version before.

Analysis 2/2 ●

Static code analysis

Criterion [static_analysis_common_vulnerabilities]
Met

Unmet

N/A

?

The project MUST use at least one static analysis tool with rules or approaches to look for common vulnerabilities in the analyzed language or environment, if there is at least one FLOSS tool that can implement this criterion in the selected language. ^{[static_analysis_common_vulnerabilities]}
Static analysis tools that are specifically designed to look for common vulnerabilities are more likely to find them. That said, using any static tools will typically help find some problems, so we are suggesting but not requiring this for the 'passing' level badge.

go vet via golangci
Dynamic code analysis

Criterion [dynamic_analysis_unsafe]
Met

Unmet

N/A

?

If the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) MUST be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). ^{[dynamic_analysis_unsafe]}
Examples of mechanisms to detect memory safety problems include Address Sanitizer (ASAN) (available in GCC and LLVM), Memory Sanitizer, and valgrind. Other potentially-used tools include thread sanitizer and undefined behavior sanitizer. Widespread assertions would also work.

go is a mem save lang

This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Anbraten and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Anbraten.
Entry created on 2021-10-11 21:43:55 UTC, last updated on 2024-06-23 23:59:32 UTC. Last achieved passing badge on 2022-08-29 23:38:21 UTC.