遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/9267)
<a href="https://www.bestpractices.dev/projects/9267"><img src="https://www.bestpractices.dev/projects/9267/badge"></a>
amp-devcontainer is a batteries-included devcontainer useable for modern, embedded, software development
https://github.com/philips-software/amp-devcontainer/blob/main/.github/CONTRIBUTING.md
There is no guidance from the enterprise on having a DCO, CAA or CLA in-place. See also https://github.com/philips-software/philips-howto-open-source
amp-devcontainer is using a code of conduct.
There are two back-up administrators from the same organization that have full rights on the repository.
https://github.com/orgs/philips-software/teams/awesome-embedded-projects
A team is the owner of the repository, with at least two users from the organization that have maintainer access on the team and admin access on the repository.
This project does not produce software but produces a devcontainer used to create software.
The security requirements and assurance case are documented in SECURITY.md
The README.md contains "quick start" information for new users, both for users that want to use amp-devcontainer as users that want to contribute.
amp-devcontainer routinely updates the documentation when a new capability is added. It is part of the PR checklist to update the documentation, and links are checked for existence by the linter.
amp-devcontainer shows several badges on the GitHub project page via the README file.
Accessibility and internationalization are outside the scope of this project. It is mostly a responsibility of the tool that is used to run the devcontainer (i.e. Visual Studio Code, JetBrains IDEs) to facilitate this.
There is no user-facing website besides the GitHub repository page which meets this criterion.
Older released versions are kept on GitHub Releases and the GitHub Container Registry (ghcr.io).
GitHub Issue tracker: https://github.com/philips-software/amp-devcontainer/issues.
There have been no vulnerabilities reported in the last 12 months.
The process of reporting and follow-up for vulnerability reports is described: https://github.com/philips-software/amp-devcontainer/blob/main/.github/SECURITY.md.
amp-devcontainer uses MegaLinter, and its default configurations, to enforce consistent style for all included languages and formats. This is enforced in a ci workflow (https://github.com/philips-software/amp-devcontainer/blob/main/.github/workflows/linting-formatting.yml).
The MegaLinter configuration can be found here: https://github.com/philips-software/amp-devcontainer/blob/main/.mega-linter.yml.
Enforced by using MegaLinter in ci (https://github.com/philips-software/amp-devcontainer/blob/main/.github/workflows/linting-formatting.yml).
amp-devcontainer uses docker/build-push-action to build the Docker containers that are the deliverables in a ci workflow found here: https://github.com/philips-software/amp-devcontainer/blob/main/.github/workflows/build-push.yml.
No applicable for Docker containers; all relevant metadata is kept.
Not relevant for Docker builds. Care has been taken that builds done as part of amp-devcontainers' workflows are fully reproduceable. I.e. version pinning, normalization of date-time information.
Care has been taken that builds done as part of amp-devcontainers' workflows are fully reproduceable. I.e. version pinning, normalization of date-time information. Following the suggestions from https://reproducible-builds.org/docs/source-date-epoch/.
Using OCI compatible images to be installed with a OCI compatible runtime. Images are hosted on ghcr.io (GitHub Container Registry).
amp-devcontainer images are fully OCI compatible.
amp-devcontainer can be updated by using OCI commands to pull and update the image.
amp-devcontainer is scanned with a dependency scanner and an SBOM is published in SPDX format towards the Release artifacts, attached to the image as attestation and submitted to the GitHub Dependency Submission API.
https://github.com/philips-software/amp-devcontainer/network/dependencies
Both Dependabot and the Container Scan action are used to scan for, and report & fix, vulnerabilities.
https://github.com/philips-software/amp-devcontainer/blob/main/.github/dependabot.yml https://github.com/philips-software/amp-devcontainer/blob/main/.github/workflows/vulnerability-scan.yml
amp-devcontainer strictly uses non-forked sources, or language specific package management systems.
For all OS packages the Ubuntu and Clang apt repositories are used. Some packages are built from source where their original GitHub repository is used. Python packages are installed using pip, Node.js packages using npm.
We avoid depending on deprecated/obsolete functions.
amp-devcontainer uses GitHub Actions to perform a large set of checks.
https://github.com/philips-software/amp-devcontainer/tree/main/.github/workflows
When regressions occur, we add tests for them.
There is an integration test suite and an end-to-end (or acceptance) test suite, but no tools are available to measure coverage in this unique scenario where the "unit under test" is a (dev)container.
A PR checklist is used to stipulate the requirements for tests of new functionality: https://github.com/philips-software/amp-devcontainer/blob/main/.github/PULL_REQUEST_TEMPLATE.md.
Linter settings are set maximally strict: https://github.com/philips-software/amp-devcontainer/blob/main/.mega-linter.yml.
Effort is spent to make the supply-chain secure when using amp-devcontainer. Release are built on GitHub ci and are signed such that the authenticity can be verified.
The only deviation from this is the usage of root as default user in the container. There are currently too many drawbacks on using a non-root user when supporting multiple host operating systems.
The containers produced as part of amp-devcontainer are signed with a tool called Cosign using a keyless signing technique prior to version 5.6.0 and with GitHub Attestations from 5.6.0 onwards.
The tags (produced by a release-please workflow) are not signed, but only the philips-forest-releaser app is allowed to create tags on the repository enforced by a repository ruleset.
The container artifacts are signed.
The output of this project is a devcontainer used for generic software development in multiple domains and languages. There is both no need, and no practical implementation of input checking that suits this use-case.
However, care is taken in the supply-chain of amp-devcontainer itself and allowlisting is employed where necessary and practical to avoid supply-chain attacks.
Both SonarQube and hadolint scan for common vulnerabilities: https://github.com/hadolint/hadolint#rules.
No unsafe languages are used for the end-product. There is C++ code in the repository, but this is only to test the end-product functionality and is not shipped as part of the end-product.
后退
级别条款。您还可以查看
或
级别条款。