Code source sécurisé

1. Présentation

Les techniques de sécurisation du code source sont un ensemble de pratiques qui peuvent être utilisées pour améliorer la sécurité du code source. Ces techniques peuvent aider à identifier et à corriger les failles du code source, à empêcher l'accès non autorisé au code source et à protéger le code source contre toute modification.

Voici quelques techniques courantes de sécurisation du code source :

• Linting : le linting est le processus de vérification du code source pour détecter les erreurs et les problèmes de style. Il est effectué à l'aide d'un outil de linting, qui est un programme qui analyse le code source et identifie les problèmes potentiels. Les outils de linting peuvent être utilisés pour vérifier diverses erreurs, y compris les erreurs de syntaxe, les erreurs sémantiques, les erreurs de style et les failles de sécurité.
• Test de sécurité des applications statiques (SAST) : le SAST est un type de test de sécurité qui analyse le code source, le code binaire ou le bytecode pour identifier les failles de sécurité. Les outils SAST peuvent être utilisés pour détecter les failles dans différents langages de programmation, y compris Go, Java, Python, C++ et C#.
• Analyse des licences : l'analyse des licences est le processus d'identification des licences des composants logiciels tiers utilisés dans une application logicielle. Cette étape est importante, car elle permet de s'assurer que l'application est conforme aux conditions des licences, ce qui peut aider à éviter les problèmes juridiques.

Ces techniques peuvent être utilisées pour améliorer la sécurité du code source à toutes les étapes du cycle de vie du développement logiciel. Le linting peut être utilisé pour identifier les erreurs au début du processus de développement, le SAST peut être utilisé pour détecter les failles avant la compilation ou le déploiement du code, et l'analyse des licences peut être utilisée pour s'assurer que l'application est conforme aux conditions des licences.

L'utilisation de ces techniques peut contribuer à améliorer la sécurité du code source et à réduire le risque de failles de sécurité.

Objectifs de l'atelier

Cet atelier se concentrera sur les outils et les techniques permettant de sécuriser le code source des logiciels.

• Linting
• Test de sécurité des applications statiques
• Analyse des licences

Tous les outils et toutes les commandes utilisés dans cet atelier seront exécutés dans Cloud Shell.

2. Préparation

Configuration de l'environnement d'auto-formation

1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

• Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pouvez la modifier à tout moment.
• L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
• Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Attention : Un ID de projet est unique. Une fois que vous l'avez choisi, personne d'autre ne peut l'employer. Vous en êtes le seul utilisateur. Même si un projet est supprimé, son ID ne peut plus jamais être utilisé.

Remarque : Si vous utilisez un compte Gmail, vous pouvez conserver l'emplacement par défaut défini sur Aucune organisation. Si vous utilisez un compte Google Workspace, choisissez un emplacement pertinent pour votre organisation.

2. Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.

Ouvrir l'éditeur Cloud Shell

Cet atelier a été conçu et testé pour être utilisé avec l'éditeur Google Cloud Shell. Pour accéder à l'éditeur :

1. Accédez à votre projet Google sur https://console.cloud.google.com.
2. En haut à droite, cliquez sur l'icône de l'éditeur Cloud Shell.

3. Un nouveau panneau s'ouvre en bas de la fenêtre.
4. Cliquez sur le bouton "Ouvrir l'éditeur".

5. L'éditeur s'ouvre avec un explorateur à droite et un éditeur dans la zone centrale.
6. Un panneau de terminal doit également être disponible en bas de l'écran.
7. Si le terminal n'est PAS ouvert, utilisez la combinaison de touches `ctrl+`` pour ouvrir une nouvelle fenêtre de terminal.

Configuration de l'environnement

Définissez le GOPATH sur un seul répertoire pour simplifier les commandes utilisées dans cet atelier.

export GOPATH=$HOME/gopath

Créez un répertoire pour stocker notre travail.

mkdir -p workspace
cd workspace

Clonez le dépôt du code source.

git clone https://gitlab.com/gcp-solutions-public/shift-left-security-workshop/source-code-lab.git
cd source-code-lab
export WORKDIR=$(pwd)

3. Linting

Le linting permet de vérifier les erreurs courantes de style ou les défauts liés à la syntaxe. Il contribue à la sécurité en fournissant un modèle de syntaxe commun à plusieurs équipes, ce qui permet d'accélérer les examens de code, le partage de connaissances et la clarté du code.

De plus, le linting identifie les erreurs de syntaxe courantes qui peuvent entraîner des failles courantes, telles qu'une utilisation incorrecte ou moins efficace des bibliothèques ou des API de base.

Installez l'outil de liaison staticcheck.

 go get honnef.co/go/tools/cmd/staticcheck@latest

Exécutez le linter Go (staticcheck) dans le répertoire racine du projet.

 staticcheck

Examinez le résultat.

main.go:42:29: unnecessary use of fmt.Sprintf (S1039)

L'erreur se produit, car http.ListenAndServe() accepte une chaîne, et le code actuel utilise Sprintf sans transmettre de variables à la chaîne.

Examinez l'état de sortie de la commande.

echo $?

Dans ce cas, comme la commande a généré une erreur, l'état de sortie sera 1 ou supérieur. Il s'agit d'une méthode qui peut être utilisée dans un pipeline CI/CD pour déterminer si l'outil a réussi ou échoué.

Modifiez le fichier main.go et corrigez le code :

• Mettez en commentaire la ligne sous LINTING - Step 1 dans la méthode main(), en ajoutant des barres obliques(//) au début.
• Annulez la mise en commentaire des deux lignes directement sous LINTING - Step 2 dans la méthode main(), en supprimant les barres obliques au début.

Exécutez de nouveau staticcheck dans le répertoire racine du projet.

staticcheck

La commande ne doit renvoyer aucun résultat (c'est-à-dire une ligne vide).

Inspectez l'état de sortie de la commande.

  echo $?

Dans ce cas, comme la commande n'a pas généré d'erreur, l'état de sortie sera zéro.

4. Test de sécurité des applications statiques

Test de sécurité AST/statique : fournit une analyse statique du code à la recherche de faiblesses et d’expositions courantes ( CWE).

Installez l'outil AST (gosec).

    export GOSEC_VERSION="2.15.0"
    curl -sfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | \
          sh -s -- -b $(go env GOPATH)/bin v${GOSEC_VERSION}

Exécutez gosec avec le fichier de règles sur le code source.

gosec -conf policies/gosec-policy.json -fmt=json ./...

Le résultat doit ressembler à ceci :

{
    "Golang errors": {},
    "Issues": [
        {
            "severity": "HIGH",
            "confidence": "LOW",
            "cwe": {
                "ID": "798",
                "URL": "https://cwe.mitre.org/data/definitions/798.html"
            },
            "rule_id": "G101",
            "details": "Potential hardcoded credentials",
            "file": "/home/random-user-here/shift-left-security-workshop/labs/source-code-lab/main.go",
            "code": "31: \t// STEP 2: Change this and the reference below to something different (ie, not \"pawsword\" or \"password\")\n32: \tvar pawsword = \"im-a-cute-puppy\"\n33: \tfmt.Println(\"Something a puppy would use: \", username, pawsword)\n",
            "line": "32",
            "column": "6"
        }
    ],
    "Stats": {
        "files": 1,
        "lines": 89,
        "nosec": 0,
        "found": 1
    }
}

L'outil a identifié un problème potentiel : Potential hardcoded credentials.

5. Analyse des licences

Les licences sont importantes pour la sécurité, car elles peuvent vous obliger légalement à exposer du code source que vous ne souhaitez peut-être pas exposer. Le concept est appelé licences "copyleft", qui vous obligent à exposer le code source si vous utilisez des dépendances avec ces licences.

Installez golicense.

mkdir -p /tmp/golicense
wget -O /tmp/golicense/golicense.tar.gz https://github.com/mitchellh/golicense/releases/download/v0.2.0/golicense_0.2.0_linux_x86_64.tar.gz
pushd /tmp/golicense
tar -xzf golicense.tar.gz
chmod +x golicense
mv golicense $(go env GOPATH)/bin/golicense
popd

Créez le fichier binaire.

go build

Exécutez la vérification des licences avec le fichier de règles actuel qui n'autorise pas les licences "BSD-3-Clause".

golicense policies/license-policy.hcl hello-world

REMARQUE : Cette opération doit échouer avec un résultat semblable à celui-ci :

 🚫 rsc.io/sampler    BSD 3-Clause "New" or "Revised" License
 🚫 rsc.io/quote      BSD 3-Clause "New" or "Revised" License
 🚫 golang.org/x/text BSD 3-Clause "New" or "Revised" License

Modifiez le fichier de règles policies/license-policy.hcl pour déplacer "BSD-3-Clause" de la liste deny vers la liste allow.

Exécutez de nouveau la vérification des licences.

golicense policies/license-policy.hcl hello-world

REMARQUE : Cette opération doit réussir avec un résultat semblable à celui-ci :

    ✅ rsc.io/quote      BSD 3-Clause "New" or "Revised" License
    ✅ rsc.io/sampler    BSD 3-Clause "New" or "Revised" License
    ✅ golang.org/x/text BSD 3-Clause "New" or "Revised" License

Pour une utilisation en production, ces commandes (et d'autres outils ciblant le code source) doivent être intégrées à un pipeline CI/CD.

6. Félicitations

Félicitations, vous avez terminé cet atelier de programmation.

Ce que vous avez appris

• Outils et techniques permettant de sécuriser le code source

—

Dernière mise à jour : 23/03/2023