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, a impedire l'accesso non autorizzato al codice sorgente e a proteggerlo da eventuali modifiche.

Alcune tecniche comuni per il codice sorgente sicuro includono:

• Linting:il linting è il processo di verifica del codice sorgente per rilevare errori e problemi di stile. Questo viene fatto utilizzando uno strumento lint, ovvero un programma che analizza il codice sorgente e identifica potenziali problemi. Gli strumenti di lint possono essere utilizzati per verificare 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 a 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 la conformità dell'applicazione ai termini delle licenze, il che può aiutarti 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, lo SAST può essere utilizzato per trovare le vulnerabilità prima della compilazione o del deployment del codice 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 licenze

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

2. Configurazione e requisiti

Configurazione dell'ambiente a tuo ritmo

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 al progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarlo in qualsiasi momento.
• L'ID progetto è univoco per tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca; in genere non è importante quale sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare il tuo e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà invariato per tutta la durata del progetto.
• Per tua informazione, esiste un terzo valore, un Numero 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 la selezione. Sei l'unico utente di quell'ID. Anche se un progetto viene eliminato, l'ID non può mai 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 le API/risorse Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non del tutto. Per arrestare le risorse in modo da non generare costi oltre questo tutorial, puoi eliminare le risorse che hai creato o l'intero progetto. I nuovi utenti di Google Cloud possono partecipare al 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. Nella parte inferiore della finestra si aprirà un nuovo riquadro
4. Fai clic sul pulsante Apri editor

5. L'editor si aprirà con un esploratore 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 errori o difetti comuni basati sullo stile relativi alla sintassi. Il linting contribuisce alla sicurezza fornendo un pattern di sintassi comune a più team, che consente di velocizzare le revisioni del codice, condividere le conoscenze e chiarire il codice.

Inoltre, il 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 il linting Go (staticcheck) nella directory principale del progetto

 staticcheck

Rivedi l'output

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

L'errore si verifica perché http.ListenAndServe() accetta una stringa e il codice corrente 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 è uno dei metodi che possono essere utilizzati in una pipeline CI/CD per determinare il successo/l'errore dello strumento.

Modifica il file main.go e correggi il codice:

• Commenta la riga sotto LINTING - Step 1 all'interno del metodo main() aggiungendo 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 risultati (ad es. 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

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

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 di criteri sul codice sorgente

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

L'output dovrebbe essere simile al seguente

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

Le licenze sono importanti per la sicurezza perché possono richiedere legalmente di esporre il codice sorgente che potresti non voler esporre. Il concetto si chiama 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

Compila il file binario

go build

Esegui il controllo della licenza con il file di criteri corrente che non consente licenze "BSD-3-Clause"

golicense policies/license-policy.hcl hello-world

NOTA: l'operazione dovrebbe non riuscire con 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: l'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

Complimenti, hai completato il codelab.

Che cosa hai imparato

• Strumenti e tecniche per proteggere il codice sorgente

—

Ultimo aggiornamento: 23/03/23