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 proteggere il codice sorgente dalla modifica.

Alcune tecniche comuni di codice sorgente sicuro includono:

• Linting:il linting è il processo di verifica della presenza di errori e problemi stilistici nel codice sorgente. Viene eseguito utilizzando uno strumento Lint, cioè un programma che analizza il codice sorgente e identifica potenziali problemi. Gli strumenti Lint consentono di verificare la presenza di diversi errori, tra cui errori di sintassi, semantici, di stile e vulnerabilità di sicurezza.
• Test di sicurezza delle applicazioni statiche (SAST): il test SAST è un tipo di test di sicurezza che analizza il codice sorgente, il codice binario o il codice byte per identificare vulnerabilità della sicurezza. Gli strumenti SAST possono essere utilizzati per individuare le vulnerabilità in una varietà di linguaggi di programmazione, tra cui Go, Java, Python, C++ e C#.
• Scansione delle licenze:la scansione delle licenze è la procedura di identificazione delle licenze dei componenti software di terze parti utilizzati in un'applicazione software. Questo passaggio è importante perché contribuisce a garantire che l'applicazione sia conforme ai termini delle licenze, evitando così problemi legali.

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

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

Cosa imparerai a fare

Questo lab è incentrato sugli strumenti e sulle tecniche per proteggere il codice sorgente del software.

• Analisi tramite lint
• Test di sicurezza delle applicazioni statiche
• Scansione delle licenze

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

2. Configurazione e requisiti

Configurazione dell'ambiente autogestito

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 progetto è il nome visualizzato dei partecipanti del progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarla in qualsiasi momento.
• L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca. di solito non ti importa cosa sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se l'ID generato non ti soddisfa, puoi generarne un altro casuale. In alternativa, puoi provarne una personalizzata per verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto.
• Per informazione, c'è 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 nessun altro utente dopo essere stato selezionato. Sei l'unico utente di quell'ID. Anche se un progetto viene eliminato, l'ID non può più essere riutilizzato

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

2. Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare risorse/API Cloud. Eseguire questo codelab non dovrebbe costare molto. Per arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial, puoi eliminare le risorse che hai creato o eliminare l'intero progetto. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.

Avvia 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 di Cloud Shell

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

5. L'editor si apre 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 un'unica directory per semplificare i comandi utilizzati in questo lab.

export GOPATH=$HOME/gopath

Crea una directory in cui lavorare

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 errori o difetti comuni basati sulla sintassi basati sugli stili. Il Linting favorisce la sicurezza fornendo un pattern di sintassi comune a più team 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 un uso improprio o meno efficiente delle librerie o delle API principali.

Installa lo strumento di collegamento di staticcheck

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

Esegui Go Linter (staticcheck) nella directory root 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

Esamina lo stato dell'uscita del comando.

echo $?

In questo caso, poiché il comando ha generato un errore, lo stato dell'uscita sarà 1 o superiore. Questo è un metodo che può essere utilizzato in una pipeline CI/CD per determinare l'esito positivo o negativo 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 dovrebbe 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 dell'uscita sarà zero.

4. Test di sicurezza delle applicazioni statiche

Test di sicurezza AST/statici: fornisce analisi statica del codice alla ricerca di punti deboli 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 dei criteri utilizzando il 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 delle licenze

Le licenze sono importanti per la sicurezza perché possono richiedere per legge di esporre il codice sorgente che non vuoi esporre. Questo concetto è chiamato " copyleft" licenze 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 della licenza con il file dei criteri corrente che non consente "BSD-3-Clause" licenze

golicense policies/license-policy.hcl hello-world

NOTA. Questa operazione non dovrebbe riuscire con 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 del criterio policies/license-policy.hcl per spostare la clausola "BSD-3-Clause" dall'elenco deny all'elenco allow.

Esegui di nuovo il controllo delle licenze

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'uso in produzione, questi comandi (e altri strumenti che hanno come target il codice sorgente) devono essere incorporati in una pipeline CI/CD.

6. Complimenti

Complimenti, hai completato il codelab.

Che cosa hai imparato

• Strumenti e tecniche per proteggere il codice sorgente

—

Ultimo aggiornamento: 23/03/23