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 vous aider à identifier et à corriger les failles dans le code source, à empêcher tout 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 : processus de vérification du code source pour détecter les erreurs et les problèmes de style. Pour ce faire, il utilise un outil lint, qui est un programme qui analyse le code source et identifie les problèmes potentiels. Les outils Lint peuvent être utilisés pour rechercher différents types d'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 trouver des 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 respecte les 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. L'analyse lint peut être utilisée pour identifier les erreurs dès le début du processus de développement, l'analyse SAST pour trouver les failles avant la compilation ou le déploiement du code, et l'analyse des licences pour s'assurer que l'application respecte les 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 concentre sur les outils et les techniques permettant de sécuriser le code source du logiciel.

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

Tous les outils et 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 le 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 du 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 au niveau mondial. 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 pas être ré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 $.

Démarrer 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 à l'adresse https://console.cloud.google.com.
2. En haut à droite, cliquez sur l'icône de l'éditeur Cloud Shell.

3. Un nouveau volet 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 volet 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 GOPATH sur un seul répertoire pour simplifier les commandes utilisées dans cet atelier.

export GOPATH=$HOME/gopath

Créer un répertoire pour stocker notre travail

mkdir -p workspace
cd workspace

Cloner 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

L'analyse lint est utilisée pour vérifier les erreurs ou les défauts courants liés au style et à la syntaxe. L'analyse lint aide à sécuriser le code en fournissant un modèle de syntaxe commun à plusieurs équipes, ce qui permet d'accélérer les revues de code, le partage des connaissances et la clarté du code.

L'analyse Lint identifie également 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 principales.

Installer l'outil d'association staticcheck

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

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

 staticcheck

Examiner le résultat

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

Vous obtenez cette erreur, 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, le code d'état de sortie sera 1 ou plus. Il s'agit d'une méthode qui peut être utilisée dans un pipeline CI/CD pour déterminer le succès ou l'échec de l'outil.

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(//).
• 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 des lignes.

Réexécutez 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 entraîné d'erreur, l'état de sortie sera zéro.

4. Tests statiques de sécurité des applications

Tests de sécurité statiques/AST : fournissent une analyse statique du code à la recherche des faiblesses et des expositions courantes ( CWE)

Installer 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écuter 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 un code source que vous ne souhaitez peut-être pas exposer. Il s'agit de licences dites de copyleft, qui vous obligent à exposer le code source si vous utilisez des dépendances avec ces licences.

Installer 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

Compiler 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 commande doit échouer et renvoyer 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 la licence "BSD-3-Clause" de la liste deny vers la liste allow.

Relancez la vérification de la licence.

golicense policies/license-policy.hcl hello-world

REMARQUE : Cette opération devrait réussir et afficher 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 pour sécuriser le code source

—

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