Code source sécurisé

1. Présentation

Les techniques de codage sécurisé 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 tout accès non autorisé au code source et à le protéger contre toute modification.

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

• Analyse lint:processus consistant à vérifier le code source à la recherche d'erreurs et de problèmes de style. Pour ce faire, vous utilisez un outil lint, qui est un programme qui analyse le code source et identifie les problèmes potentiels. Les outils lint permettent de rechercher diverses erreurs, y compris des erreurs de syntaxe, des erreurs sémantiques, des erreurs de style et des failles de sécurité.
• Test de sécurité des applications statiques (SAST, Static Application Security Testing) : type de test de sécurité qui analyse le code source, le code binaire ou le code octet pour identifier les failles de sécurité. Les outils SAST permettent de détecter des failles dans divers langages de programmation, y compris Go, Java, Python, C++ et C#.
• Analyse des licences:processus permettant d'identifier les licences des composants logiciels tiers utilisés dans une application logicielle. Cela est important, car cela 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. Le linting permet d'identifier les erreurs au début du processus de développement, le SAST permet de détecter les failles avant la compilation ou le déploiement du code, et l'analyse des licences permet de 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 violation de la sécurité.

Objectifs de l'atelier

Cet atelier se concentre sur les outils et les techniques permettant de sécuriser le code source d'un logiciel.

• Linting
• Tests de sécurité des applications statiques
• 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 mettre à jour à 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 au niveau mondial. Personne d'autre ne peut l'employer une fois que vous l'avez sélectionné. 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 gratuit 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 sur la droite et l'é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 notre travail

mkdir -p workspace
cd workspace

Cloner le dépôt de 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 ou les défauts courants liés à la syntaxe ou au style. L'analyse linting contribue à la sécurité en fournissant un modèle de syntaxe commun à plusieurs équipes, ce qui permet d'accélérer les revues de code, de partager des connaissances et de clarifier le 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 principales.

Installer l'outil de liaison staticcheck

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

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

 staticcheck

Examiner le résultat

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

Vous recevez cette erreur, car http.ListenAndServe() accepte une chaîne, et le code actuel utilise Sprintf sans transmettre de variables à la chaîne.

Vérifiez 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 pouvant ê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:

• Commentez la ligne située 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 situées directement sous LINTING - Step 2 dans la méthode main() en supprimant les barres obliques initiales.

Exécuter à 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 est zéro.

4. Tests de sécurité des applications statiques

AST/Tests de sécurité statiques : analyse du code statique à la recherche de failles et d'expositions courantes ( CWEs)

Installer l'outil d'analyse statique du code (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 devrait 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. Ce concept est appelé "licences copyleft". Elles 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

Compiler le fichier binaire

go build

Exécuter la vérification de la licence avec le fichier de stratégie 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:

 🚫 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 clause BSD-3 de la liste deny vers la liste allow.

Relancer la vérification de licence

golicense policies/license-policy.hcl hello-world

REMARQUE: L'opération devrait réussir et le résultat devrait ressembler à ceci:

    ✅ 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/23