Codice sorgente sicuro

1. Panoramica

Le tecniche di codice sorgente sicuro sono un insieme di pratiche che possono essere utilizzate per migliorare la sicurezza del codice sorgente. Queste tecniche possono aiutare a identificare e correggere le vulnerabilità nel codice sorgente, impedire l'accesso non autorizzato al codice sorgente e proteggerlo da modifiche.

Alcune tecniche comuni per il codice sorgente sicuro includono:

• Linting:il linting è il processo di controllo del codice sorgente per rilevare errori e problemi stilistici. Viene eseguita utilizzando uno strumento lint, un programma che analizza il codice sorgente e identifica potenziali problemi. Gli strumenti di analisi statica del codice possono essere utilizzati per verificare la presenza di una serie di errori, tra cui errori di sintassi, errori semantici, errori di stile e vulnerabilità di sicurezza.
• Test di sicurezza delle applicazioni statiche (SAST): SAST è un tipo di test di sicurezza che analizza il codice sorgente, il codice binario o il codice byte per identificare le vulnerabilità di sicurezza. Gli strumenti SAST possono essere utilizzati per trovare vulnerabilità in una serie di linguaggi di programmazione, tra cui Go, Java, Python, C++ e C#.
• Scansione delle licenze:la scansione delle licenze è il processo di identificazione delle licenze dei componenti software di terze parti utilizzati in un'applicazione software. Questo è importante perché contribuisce a garantire che l'applicazione rispetti i termini delle licenze, il che può aiutare a evitare problemi legali.

Queste tecniche possono essere utilizzate per migliorare la sicurezza del codice sorgente in tutte le fasi del ciclo di vita dello sviluppo software. Il linting può essere utilizzato per identificare gli errori nelle prime fasi del processo di sviluppo, SAST può essere utilizzato per trovare le vulnerabilità prima che il codice venga compilato o implementato e la scansione delle licenze può essere utilizzata per garantire che l'applicazione sia conforme ai termini delle licenze.

L'utilizzo di queste tecniche può contribuire a migliorare la sicurezza del codice sorgente e a ridurre il rischio di violazioni della sicurezza.

Cosa imparerai a fare

Questo lab si concentrerà sugli strumenti e sulle tecniche per proteggere il codice sorgente del software.

• Analisi tramite lint
• Test di sicurezza delle applicazioni statiche
• Scansione della licenza

Tutti gli strumenti e i comandi utilizzati in questo lab verranno eseguiti in Cloud Shell.

2. Configurazione e requisiti

Configurazione dell'ambiente autonomo

1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

• Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarlo in qualsiasi momento.
• L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se non ti piace l'ID generato, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto.
• Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.

Attenzione:un ID progetto è univoco a livello globale e non può essere utilizzato da altri dopo che lo hai selezionato. Sei l'unico utente di questo ID. Anche se un progetto viene eliminato, l'ID non potrà mai più essere utilizzato

Nota:se utilizzi un account Gmail, puoi lasciare la località predefinita impostata su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una posizione adatta alla tua organizzazione.

2. Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non nulla. Per arrestare le risorse in modo da non incorrere in costi di fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o l'intero progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.

Avvia l'editor di Cloud Shell

Questo lab è stato progettato e testato per l'utilizzo con l'editor di Google Cloud Shell. Per accedere all'editor:

1. Accedi al tuo progetto Google all'indirizzo https://console.cloud.google.com.
2. Nell'angolo in alto a destra, fai clic sull'icona dell'editor Cloud Shell.

3. Si aprirà un nuovo riquadro nella parte inferiore della finestra.
4. Fai clic sul pulsante Apri editor.

5. L'editor si aprirà con un explorer a destra e l'editor nell'area centrale
6. Nella parte inferiore dello schermo dovrebbe essere disponibile anche un riquadro del terminale
7. Se il terminale NON è aperto, utilizza la combinazione di tasti "Ctrl + `" per aprire una nuova finestra del terminale.

Configurazione dell'ambiente

Imposta GOPATH su una singola directory per semplificare i comandi utilizzati in questo lab.

export GOPATH=$HOME/gopath

Crea una directory per contenere il nostro lavoro

mkdir -p workspace
cd workspace

Clona il repository del codice sorgente

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

3. Analisi tramite lint

Il linting viene utilizzato per verificare la presenza di errori o difetti comuni basati sullo stile e relativi alla sintassi. Linting aiuta la sicurezza fornendo un pattern di sintassi comune a più team, il che porta a revisioni del codice più rapide, condivisione delle conoscenze e chiarezza del codice.

Inoltre, Linting identifica gli errori di sintassi comuni che possono portare a vulnerabilità comuni, come l'uso improprio o meno efficiente di librerie o API di base.

Installa lo strumento di collegamento staticcheck

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

Esegui Go Linter (staticcheck) nella directory principale del progetto

 staticcheck

Rivedi l'output

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

Ricevi l'errore perché http.ListenAndServe() accetta una stringa e il codice attuale utilizza Sprintf senza passare variabili alla stringa

Controlla lo stato di uscita del comando.

echo $?

In questo caso, poiché il comando ha generato un errore, lo stato di uscita sarà 1 o superiore. Questo è un metodo che può essere utilizzato in una pipeline CI/CD per determinare la riuscita o il mancato funzionamento dello strumento.

Modifica il file main.go e correggi il codice:

• Commenta la riga sotto LINTING - Step 1 all'interno del metodo main() aggiungendo le barre iniziali(//).
• Rimuovi il commento dalle due righe direttamente sotto LINTING - Step 2 all'interno del metodo main() rimuovendo le barre iniziali.

Esegui di nuovo staticcheck nella directory principale del progetto

staticcheck

Il comando non deve restituire alcun risultato (ovvero una riga vuota).

Controlla lo stato di uscita del comando.

  echo $?

In questo caso, poiché il comando non ha generato un errore, lo stato di uscita sarà zero.

4. Test di sicurezza delle applicazioni statiche

Test di sicurezza AST/statico: fornisce un'analisi statica del codice alla ricerca di debolezze ed esposizioni comuni ( CWE)

Installa lo strumento 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}

Esegui gosec con il file delle norme sul codice sorgente

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

L'output dovrebbe essere simile a questo

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

Lo strumento ha identificato un potenziale problema: Potential hardcoded credentials

5. Scansione della licenza

Le licenze sono importanti per la sicurezza perché possono richiedere legalmente di esporre il codice sorgente che potresti non voler esporre. Il concetto è chiamato licenze "copyleft", che richiedono di esporre il codice sorgente se utilizzi dipendenze con queste licenze.

Installa 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

Crea il file binario

go build

Esegui il controllo delle licenze con il file delle norme attuale che non consente le licenze "BSD-3-Clause"

golicense policies/license-policy.hcl hello-world

NOTA: questo comando dovrebbe non riuscire e restituire un output simile:

 🚫 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

Modifica il file delle norme policies/license-policy.hcl per spostare "BSD-3-Clause" dall'elenco deny all'elenco allow.

Esegui di nuovo il controllo della licenza

golicense policies/license-policy.hcl hello-world

NOTA: questa operazione dovrebbe riuscire con un output simile:

    ✅ 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

Per l'utilizzo in produzione, questi comandi (e altri strumenti che hanno come target il codice sorgente) devono essere incorporati in una pipeline CI/CD.

6. Complimenti

Congratulazioni, hai completato il codelab.

Cosa hai imparato

• Strumenti e tecniche per proteggere il codice sorgente

—

Ultimo aggiornamento: 23/03/2023