cosign
JaCoCo
cosign | JaCoCo | |
---|---|---|
30 | 7 | |
4,068 | 4,016 | |
1.7% | 0.5% | |
9.6 | 8.3 | |
9 days ago | 9 days ago | |
Go | Java | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cosign
-
Securing CI/CD Images with Cosign and OPA
Cosign: In this context, Cosign from the Sigstore project offers a compelling solution. Its simplicity, registry compatibility, and effective link between images and their signatures provide a user-friendly and versatile approach. The integration of Fulcio for certificate management and Rekor for secure logging enhances Cosign's appeal, making it particularly suitable for modern development environments that prioritize security and agility.
-
An Overview of Kubernetes Security Projects at KubeCon Europe 2023
sigstore is another suite of tools that focuses on attestation and provenance. Within the suite are two tools I heard mentioned a few times at KubeCon: Cosign and Rekor.
-
Spin 1.0 ā The Developer Tool for Serverless WebAssembly
Since we can distribute Spin applications using popular registry services, we can also take advantage of ecosystem tools such as Sigstore and Cosign, which address the software supply chain issue by signing and verifying applications using Sigstore's new keyless signatures (using OIDC identity tokens from providers such as GitHub).
-
Iron Bank: Secure Registries, Secure Containers
Use distroless images (which contain only application and its runtime dependencies, and don't include package managers/shells or any other programs you would expect to find in a standard Linux distribution). All distroless images are signed by cosign.
-
Getting hands on with Sigstore Cosign on AWS
$ COSIGN_EXPERIMENTAL=1 cosign verify-blob --cert https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64-keyless.pem --signature https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64-keyless.sig https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64
-
How much are you 'trusting' a docker image from hub.docker.com?
Another thing to look for is, whether the image is signed using something like cosign (https://github.com/sigstore/cosign). This lets the publisher digitally sign the image, so you at least know that what's on the registry is what they intended to put there. Handy to avoid the risks of attackers squatting similar names and catching typos.
-
What security controls to prevent someone from pushing arbitrary code into production?
iām late but surprised no one has mentioned cosign
-
Docker build fails on GitHub Action after net7 update
name: Docker # This workflow uses actions that are not certified by GitHub. # They are provided by a third-party and are governed by # separate terms of service, privacy policy, and support # documentation. on: push: branches: [ "main" ] # Publish semver tags as releases. tags: [ 'v*.*.*' ] pull_request: branches: [ "main" ] paths: - src/MamisSolidarias.WebAPI.Campaigns/Dockerfile - .github/workflows/docker-publish.yml workflow_dispatch: env: # Use docker.io for Docker Hub if empty REGISTRY: ghcr.io IMAGE_NAME: mamis-solidarias/campaigns jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write # This is used to complete the identity challenge # with sigstore/fulcio when running outside of PRs. id-token: write steps: - name: Checkout repository uses: actions/checkout@v3 # Install the cosign tool except on PR # https://github.com/sigstore/cosign-installer - name: Install cosign if: github.event_name != 'pull_request' uses: sigstore/cosign-installer@main with: cosign-release: 'v1.13.1' - name: Set up QEMU uses: docker/setup-qemu-action@v2 with: platforms: 'arm64' # Workaround: https://github.com/docker/build-push-action/issues/461 - name: Setup Docker buildx uses: docker/setup-buildx-action@v2 # Login against a Docker registry except on PR # https://github.com/docker/login-action - name: Log into registry ${{ env.REGISTRY }} if: github.event_name != 'pull_request' uses: docker/login-action@v2 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} # Extract metadata (tags, labels) for Docker # https://github.com/docker/metadata-action - name: Extract Docker metadata id: meta uses: docker/metadata-action@v4 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} tags: | type=schedule type=ref,event=branch type=ref,event=pr type=semver,pattern={{version}} type=semver,pattern={{major}}.{{minor}} type=semver,pattern={{major}} type=sha # Build and push Docker image with Buildx (don't push on PR) # https://github.com/docker/build-push-action - name: Build and push Docker image id: build-and-push uses: docker/build-push-action@v3 with: context: . platforms: linux/amd64, linux/arm64 file: src/MamisSolidarias.WebAPI.Campaigns/Dockerfile push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} # Sign the resulting Docker image digest except on PRs. # This will only write to the public Rekor transparency log when the Docker # repository is public to avoid leaking data. If you would like to publish # transparency data even for private images, pass --force to cosign below. # https://github.com/sigstore/cosign - name: Sign the published Docker image if: ${{ github.event_name != 'pull_request' }} env: COSIGN_EXPERIMENTAL: "true" # This step uses the identity token to provision an ephemeral certificate # against the sigstore community Fulcio instance. run: echo "${{ steps.meta.outputs.tags }}" | xargs -I {} cosign sign {}@${{ steps.build-and-push.outputs.digest }}
-
How to tag base image so images built from it can be tracked
After inspecting the layers i think you should start thinking about signing your images: https://github.com/sigstore/cosign/
-
Understanding Kubernetes Limits and Requests
cosign
JaCoCo
-
Apache Maven JaCoCo Configuration
I will use here JaCoCo, where also the JaCoCo-Maven-lugin exists for the usage in your Maven builds. This article will show how to configure the code coverage to finally get the results for unit- and integration-tests.
-
HRV-Mart
In protection rules, I added build workflow in Require status checks to pass before merging. This is to ensure that before merging code in master branch, build should run successfully. I also added Jacoco Code Coverage to make sure that enough unit tests are available in project and Detekt to make sure that code in project is readable. I added them in build configuration. Even if one of them gives error, build will fail. Whenever, someone push code in pull request, build action will run and check if build is running successfully or not.
-
CI/CD with Spring Boot and Jenkins Pipelines
Code coverage analysis tools quantify the amount of tested code, serving as a valuable tool to inform on code structure and testing related decisions. We will make use of JaCoCo, JaCoCo produces reports on multiple kinds of code coverage metrics including instructions, line and branch coverage.
-
How to Use Maven Profiles to Selectively Activate Plugins and Other Configuration from the Command Line
One specific example where I regularly use a profile in this way is for configuring code coverage. In all of my Java projects, I use JaCoCo for generating code coverage reports. I use JaCoCo during the Maven test phase. However, while developing I find it useful at times to exclude coverage reporting to reduce the build time. But in my CI/CD workflows in GitHub Actions, I activate the code coverage profile during pull-requests and pushes to the default branch. For pull-requests, my GitHub Actions workflow comments the code coverage on the PR and uploads the coverage report as a workflow artifact, where I can inspect it as necessary. And during a push to the default branch, my workflow updates coverage badges to keep them up to date with the current state of the default branch. I can also activate the code coverage profile locally while developing, such as prior to submitting a pull-request, to ensure that I didn't miss testing something.
-
Implement DevSecOps to Secure your CI/CD pipeline
In Unit tests, individual software code components are checked if it is working as expected or not. Unit tests isolate a function or module of code and verify its correctness. We can use tools like JaCoCo for Java and Mocha, and Jasmine for NodeJS to generate unit test reports. We can also send these reports to SonarQube which shows us code coverage and the percentage of your code covered by your test cases.
-
Which Jacoco Android plugin you're using for test coverage?
And there is the original jacoco/jacoco: (0.8.7: released this on May 5, 2021), but it's for Java. I'm not sure if we can use it with multiple flavors on Android.
-
Kotlin 1.5.0 ā the First Big Release of 2021
Make sure to also update to Jacoco 0.8.7 to avoid test issues: https://github.com/jacoco/jacoco/releases/tag/v0.8.7
What are some alternatives?
notation - A CLI tool to sign and verify artifacts
Cobertura - Cobertura
in-toto-golang - A Go implementation of in-toto. in-toto is a framework to protect software supply chain integrity.
sonar-flutter - SonarQube plugin for Flutter / Dart
connaisseur - An admission controller that integrates Container Image Signature Verification into a Kubernetes cluster
Micronaut - Micronaut Application Framework
spire - The SPIFFE Runtime Environment
gradle-android-junit-jacoco-plugin - Gradle plugin that generates JaCoCo reports from an Android Gradle Project
spiffe-vault - Integrates Spiffe and Vault to have secretless authentication
proguard-core - Library to read, write, analyze, and process java bytecode
rekor - Software Supply Chain Transparency Log
Cobalt - Standalone unofficial fully-featured Whatsapp Web and Mobile API for Java and Kotlin