Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
trivy-action — Exécute Trivy en tant qu'action GitHub pour analyser votre image de conteneur Docker à la recherche de vulnérabilités | Kitploit
Outils/GitHubGitHub/aquasecurity/trivy-action
Scanners de VulnérabilitésSécurité des ConteneursAnalyse de CodeSécurité CloudDevSecOpsDétection de SecretsSécurité de la Chaîne LogistiqueMauvaise Configuration
GitHubaquasecurity/trivy-action

trivy-action

Exécute Trivy en tant qu'action GitHub pour analyser votre image de conteneur Docker à la recherche de vulnérabilités

Voir le dépôt
1.4k35727il y a 1 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Action Trivy

Action GitHub pour Trivy

[![GitHub Release][release-img]][release] [![GitHub Marketplace][marketplace-img]][marketplace] [![License][license-img]][license]

Table des matières

  • Utilisation
    • Analyser le pipeline CI
    • Analyser le pipeline CI (avec configuration Trivy)
    • Cache
    • Configuration de Trivy
    • Analyser une archive Tarball
    • Utiliser Trivy avec des modèles
    • Utiliser Trivy avec GitHub Code Scanning
    • Utiliser Trivy pour analyser votre dépôt Git
    • Utiliser Trivy pour analyser vos répertoires rootfs
    • Utiliser Trivy pour analyser l’infrastructure en tant que code
    • Utiliser Trivy pour générer un SBOM
    • Utiliser Trivy pour analyser votre registre privé
    • Utiliser Trivy si vous n’avez pas activé le scanning de code
  • Personnalisation
    • Entrées
    • Variables d’environnement
    • Fichier de configuration Trivy

Utilisation

Analyser le pipeline CI```yaml

name: build on: push: branches: - main pull_request: jobs: build: name: Build runs-on: ubuntu-24.04 steps: - name: Checkout code uses: actions/checkout@v4 - name: Build an image from Dockerfile run: docker build -t docker.io/my-organization/my-app:${{ github.sha }} . - name: Run Trivy vulnerability scanner uses: aquasecurity/[email protected] with: image-ref: 'docker.io/my-organization/my-app:${{ github.sha }}' format: 'table' exit-code: '1' ignore-unfixed: true vuln-type: 'os,library' severity: 'CRITICAL,HIGH'

### Pipeline CI de Scan (avec configuration Trivy)```yaml
name: build
on:
  push:
    branches:
    - main
  pull_request:
jobs:
  build:
    name: Build
    runs-on: ubuntu-24.04
    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Run Trivy vulnerability scanner in fs mode
      uses: aquasecurity/[email protected]
      with:
        scan-type: 'fs'
        scan-ref: '.'
        trivy-config: trivy.yaml

Dans ce cas, trivy.yaml est une configuration YAML qui est incluse dans le dépôt. Des informations détaillées sont disponibles sur le site web de Trivy, mais un exemple est le suivant :```yaml format: json exit-code: 1 severity: CRITICAL secret: config: config/trivy/secret.yaml

Il est possible de définir toutes les options dans le fichier `trivy.yaml`. La spécification d'options individuelles via l'action est conservée à des fins de rétrocompatibilité. La définition des éléments suivants est nécessaire car ils ne peuvent pas être définis avec le fichier de configuration :
- `scan-ref` : si vous utilisez les analyses `fs, repo`.
- `image-ref` : si vous utilisez l'analyse `image`.
- `scan-type` : pour définir le type d'analyse, par ex. `image`, `fs`, `repo`, etc.

#### Ordre de préférence des options
Trivy utilise [Viper](https://github.com/spf13/viper) qui a un ordre de priorité défini pour les options. L'ordre est le suivant :
- Drapeau de l'action GitHub
- Variable d'environnement
- Fichier de configuration
- Par défaut

### Cache
L'action intègre une fonctionnalité de mise en cache et de restauration [de la base de données de vulnérabilités](https://github.com/aquasecurity/trivy-db), [de la base de données Java](https://github.com/aquasecurity/trivy-java-db) et [du bundle de vérifications](https://github.com/aquasecurity/trivy-checks) s'ils sont téléchargés lors de l'analyse.
Le cache est stocké par défaut dans le répertoire `$GITHUB_WORKSPACE/.cache/trivy`.
Le cache est restauré avant le début de l'analyse et enregistré après la fin de l'analyse.

Il utilise [actions/cache](https://github.com/actions/cache) en interne mais nécessite moins de paramètres de configuration.
L'entrée du cache est facultative et la mise en cache est activée par défaut.

#### Désactiver la mise en cache
Si vous souhaitez désactiver la mise en cache, définissez l'entrée `cache` sur `false`, mais nous recommandons de la garder activée pour éviter les problèmes de limitation de débit.```yaml
    - name: Run Trivy scanner without cache
      uses: aquasecurity/[email protected]
      with:
        scan-type: 'fs'
        scan-ref: '.'
        cache: 'false'

Mise à jour des caches dans la branche par défaut

Veuillez noter qu'il existe des restrictions sur l'accès au cache entre les branches dans GitHub Actions. Par défaut, un workflow peut accéder et restaurer un cache créé soit dans la branche courante, soit dans la branche par défaut (généralement main ou master). Si vous devez partager des caches entre branches, vous devrez peut-être créer un cache dans la branche par défaut et le restaurer dans la branche courante.

Pour optimiser votre workflow, vous pouvez configurer une tâche cron pour mettre à jour régulièrement le cache dans la branche par défaut. Cela permet aux analyses suivantes d'utiliser la base de données (DB) en cache sans la télécharger à nouveau.```yaml

Note: This workflow only updates the cache. You should create a separate workflow for your actual Trivy scans.

In your scan workflow, set TRIVY_SKIP_DB_UPDATE=true and TRIVY_SKIP_JAVA_DB_UPDATE=true.

name: Update Trivy Cache

on: schedule: - cron: '0 0 * * *' # Run daily at midnight UTC workflow_dispatch: # Allow manual triggering

jobs: update-trivy-db: runs-on: ubuntu-latest steps: - name: Setup oras uses: oras-project/setup-oras@v1

  - name: Get current date
    id: date
    run: echo "date=$(date +'%Y-%m-%d')" >> $GITHUB_OUTPUT

  - name: Download and extract the vulnerability DB
    run: |
      mkdir -p $GITHUB_WORKSPACE/.cache/trivy/db
      oras pull ghcr.io/aquasecurity/trivy-db:2
      tar -xzf db.tar.gz -C $GITHUB_WORKSPACE/.cache/trivy/db
      rm db.tar.gz

  - name: Download and extract the Java DB
    run: |
      mkdir -p $GITHUB_WORKSPACE/.cache/trivy/java-db
      oras pull ghcr.io/aquasecurity/trivy-java-db:1
      tar -xzf javadb.tar.gz -C $GITHUB_WORKSPACE/.cache/trivy/java-db
      rm javadb.tar.gz
Télécharger l’outil