Diese Seite wurde von der Cloud Translation API übersetzt.

Sicherer Quellcode

1. Übersicht

Mit sicheren Quellcode-Techniken können Sie die Sicherheit des Quellcodes verbessern. Mit diesen Techniken können Sie Sicherheitslücken im Quellcode identifizieren und beheben, unbefugten Zugriff auf den Quellcode verhindern und den Quellcode vor Änderungen schützen.

Zu den gängigen Techniken für sicheren Quellcode gehören:

Linting: Beim Linting wird der Quellcode auf Fehler und stilistische Probleme geprüft. Dazu wird ein Lint-Tool verwendet, ein Programm, das den Quellcode analysiert und potenzielle Probleme identifiziert. Mit Lint-Tools können Sie nach einer Vielzahl von Fehlern suchen, einschließlich Syntaxfehlern, semantischen Fehlern, Stilfehlern und Sicherheitslücken.
Static Application Security Testing (SAST): SAST ist eine Art von Sicherheitstest, bei dem Quellcode, Binärcode oder Bytecode analysiert wird, um Sicherheitslücken zu identifizieren. Mit SAST-Tools lassen sich Sicherheitslücken in einer Vielzahl von Programmiersprachen finden, darunter Go, Java, Python, C++ und C#.
Lizenzprüfung: Bei der Lizenzprüfung werden die Lizenzen von Softwarekomponenten von Drittanbietern identifiziert, die in einer Softwareanwendung verwendet werden. Das ist wichtig, da so sichergestellt werden kann, dass die Anwendung den Lizenzbedingungen entspricht, was rechtliche Probleme vermeiden kann.

Mit diesen Techniken lässt sich die Sicherheit des Quellcodes in allen Phasen des Softwareentwicklungszyklus verbessern. Mit Linting können Fehler schon früh im Entwicklungsprozess erkannt werden, mit SAST können Sicherheitslücken gefunden werden, bevor der Code kompiliert oder bereitgestellt wird, und mit dem Lizenz-Scan kann sichergestellt werden, dass die Anwendung den Lizenzbedingungen entspricht.

Mit diesen Techniken lässt sich die Sicherheit des Quellcodes verbessern und das Risiko von Sicherheitsverletzungen reduzieren.

Lerninhalte

In diesem Lab liegt der Schwerpunkt auf den Tools und Techniken zum Schutz des Software-Quellcodes.

Linting
Static Application Security Testing
Lizenzprüfung

Alle in diesem Lab verwendeten Tools und Befehle werden in Cloud Shell ausgeführt.

2. Einrichtung und Anforderungen

Einrichten der Umgebung im eigenen Tempo

Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Gerät testen, um zu sehen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Als Nächstes müssen Sie in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Ausführung dieses Codelabs sollte nur wenige Kosten verursachen, wenn überhaupt. Wenn Sie die Ressourcen deaktivieren möchten, damit keine Kosten über diese Anleitung hinaus anfallen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Cloud Shell-Editor starten

Dieses Lab wurde für die Verwendung mit dem Google Cloud Shell-Editor entwickelt und getestet. So greifen Sie auf den Editor zu:

Rufen Sie Ihr Google-Projekt unter https://console.cloud.google.com auf.
Klicken Sie oben rechts auf das Cloud Shell-Editorsymbol.

Unten im Fenster wird ein neuer Bereich geöffnet.
Klicken Sie auf die Schaltfläche „Editor öffnen“.

Der Editor wird mit einem Explorer auf der rechten Seite und dem Editor im zentralen Bereich geöffnet.
Unten auf dem Bildschirm sollte auch ein Terminalbereich verfügbar sein.
Wenn das Terminal NICHT geöffnet ist, verwenden Sie die Tastenkombination „Strg + „, um ein neues Terminalfenster zu öffnen.

Umgebung einrichten

Legen Sie GOPATH auf ein einzelnes Verzeichnis fest, um die Befehle in diesem Lab zu vereinfachen.

export GOPATH=$HOME/gopath

Erstellen Sie ein Verzeichnis für unsere Arbeit.

mkdir -p workspace
cd workspace

Quellcode-Repository klonen

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

Mit Linting werden häufige stilistische Fehler oder Syntaxfehler geprüft. Linting trägt zur Sicherheit bei, da es ein gemeinsames Syntaxmuster für mehrere Teams bietet, was zu schnelleren Codeüberprüfungen, Wissensaustausch und Klarheit des Codes führt.

Außerdem werden mit Linting häufige Syntaxfehler erkannt, die zu häufigen Sicherheitslücken führen können, z. B. eine unangemessene oder weniger effiziente Verwendung von Bibliotheken oder Kern-APIs.

staticcheck-Verknüpfungstool installieren

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

Führen Sie den Go-Linter (staticcheck) im Stammverzeichnis des Projekts aus.

 staticcheck

Ausgabe prüfen

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

Der Fehler tritt auf, weil http.ListenAndServe() einen String akzeptiert und im aktuellen Code Sprintf verwendet wird, ohne Variablen an den String zu übergeben.

Prüfen Sie den Exit-Status des Befehls.

echo $?

Da der Befehl in diesem Fall zu einem Fehler geführt hat, ist der Beendigungsstatus 1 oder höher. Dies ist eine Methode, die in einer CI/CD-Pipeline verwendet werden kann, um den Erfolg oder Misserfolg des Tools zu bestimmen.

Bearbeiten Sie die Datei main.go und korrigieren Sie den Code:

Kommentieren Sie die Zeile unter LINTING - Step 1 in der main()-Methode, indem Sie vorangestellte Schrägstriche(//) hinzufügen.
Entfernen Sie die Kommentarzeichen vor den beiden Zeilen direkt unter LINTING - Step 2 in der Methode main().

staticcheck noch einmal im Stammverzeichnis des Projekts ausführen

staticcheck

Der Befehl sollte keine Ergebnisse zurückgeben, d.h. eine leere Zeile.

Prüfen Sie den Beendigungsstatus des Befehls.

  echo $?

Da der Befehl in diesem Fall keinen Fehler verursacht hat, ist der Exit-Status null.

4. Static Application Security Testing

AST/Static Security Testing: Statische Codeanalyse, bei der nach häufigen Schwachstellen und Sicherheitslücken ( CWEs) gesucht wird

AST-Tool (gosec) installieren

    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}

gosec mit Richtliniendatei auf den Quellcode anwenden

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

Die Ausgabe sollte in etwa so aussehen:

{
    "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
    }
}

Das Tool hat ein potenzielles Problem erkannt: Potential hardcoded credentials

5. Lizenzprüfung

Lizenzen sind für die Sicherheit wichtig, da Sie gesetzlich verpflichtet sein können, Quellcode offenzulegen, den Sie möglicherweise nicht offenlegen möchten. Das Konzept wird als copyleft-Lizenz bezeichnet. Bei diesen Lizenzen müssen Sie den Quellcode offenlegen, wenn Sie Abhängigkeiten mit diesen Lizenzen verwenden.

golicense installieren

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

Binärdatei erstellen

go build

Führen Sie die Lizenzprüfung mit der aktuellen Richtliniendatei durch, in der keine „BSD-3-Clause“-Lizenzen zulässig sind.

golicense policies/license-policy.hcl hello-world

HINWEIS: Dies sollte mit einer ähnlichen Ausgabe fehlschlagen:

 🚫 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

Ändern Sie die Richtliniendatei policies/license-policy.hcl, um „BSD-3-Clause“ aus der Liste deny in die Liste allow zu verschieben.

Lizenzüberprüfung noch einmal durchführen

golicense policies/license-policy.hcl hello-world

HINWEIS: Die Ausgabe sollte in etwa so aussehen:

    ✅ 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

6. Glückwunsch

Herzlichen Glückwunsch, Sie haben das Codelab abgeschlossen.

Was Sie gelernt haben

Tools und Techniken zum Schutz des Quellcodes

–

Letzte Aktualisierung: 23.03.23