Código-fonte seguro

1. Visão geral

As técnicas de código-fonte seguro são um conjunto de práticas que podem ser usadas para melhorar a segurança do código-fonte. Essas técnicas podem ajudar a identificar e corrigir vulnerabilidades no código-fonte, impedir o acesso não autorizado e proteger o código-fonte contra modificações.

Algumas técnicas comuns de código-fonte seguro incluem:

• Linting:é o processo de verificar se há erros e problemas estilísticos no código-fonte. Isso é feito usando uma ferramenta lint, que é um programa que analisa o código-fonte e identifica possíveis problemas. As ferramentas de lint podem ser usadas para verificar vários erros, incluindo erros de sintaxe, erros semânticos, erros de estilo e vulnerabilidades de segurança.
• Teste estático de segurança de aplicativos (SAST, na sigla em inglês): o SAST é um tipo de teste de segurança que analisa o código-fonte, o código binário ou o código de bytes para identificar vulnerabilidades de segurança. As ferramentas SAST podem ser usadas para encontrar vulnerabilidades em várias linguagens de programação, incluindo Go, Java, Python, C++ e C#.
• Verificação de licença:é o processo de identificação das licenças de componentes de software de terceiros usados em um aplicativo de software. Isso é importante porque ajuda a garantir que o aplicativo obedeça aos termos das licenças, o que pode ajudar a evitar problemas legais.

Essas técnicas podem ser usadas para melhorar a segurança do código-fonte em todas as etapas do ciclo de vida do desenvolvimento de software. O linting pode ser usado para identificar erros no início do processo de desenvolvimento. O SAST pode ser usado para encontrar vulnerabilidades antes que o código seja compilado ou implantado. A verificação de licença pode ser usada para garantir que o aplicativo esteja em conformidade com os termos das licenças.

O uso dessas técnicas pode ajudar a melhorar a segurança do código-fonte e reduzir o risco de violações de segurança.

O que você vai aprender

Este laboratório vai se concentrar nas ferramentas e técnicas para proteger o código-fonte do software.

• Inspecionar
• Teste estático de segurança de aplicativos
• Verificação de licença

Todas as ferramentas e comandos usados neste laboratório serão executados no Cloud Shell.

2. Configuração e requisitos

Configuração de ambiente personalizada

1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

• O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google É possível atualizar o local a qualquer momento.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
• Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção:o ID do projeto é globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.

Observação: se você estiver usando uma conta do Gmail, deixe o local padrão definido como Sem organização. Se você estiver usando uma conta do Google Workspace, escolha um local adequado para a organização.

2. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto inteiro. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Iniciar o editor do Cloud Shell

Este laboratório foi criado e testado para uso com o editor do Google Cloud Shell. Para acessar o editor,

1. Acesse seu projeto do Google em https://console.cloud.google.com.
2. No canto superior direito, clique no ícone do editor do Cloud Shell.

3. Um novo painel será aberto na parte de baixo da janela.
4. Clique no botão "Abrir editor".

5. O editor vai abrir com um explorador à direita e o editor na área central.
6. Um painel de terminal também estará disponível na parte de baixo da tela.
7. Se o terminal NÃO estiver aberto, use a combinação de teclas "Ctrl+" para abrir uma nova janela de terminal.

Configuração do ambiente

Defina o GOPATH como um único diretório para simplificar os comandos usados neste laboratório.

export GOPATH=$HOME/gopath

Criar um diretório para armazenar nosso trabalho

mkdir -p workspace
cd workspace

Clone o repositório de código-fonte

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

3. Inspecionar

O linting é usado para verificar erros ou defeitos comuns relacionados à sintaxe. O linting auxilia na segurança, fornecendo um padrão de sintaxe comum para várias equipes, o que resulta em revisões de código mais rápidas, compartilhamento de conhecimento e clareza do código.

Além disso, o linting identifica erros de sintaxe comuns que podem levar a vulnerabilidades comuns, como uso inadequado ou menos eficiente de bibliotecas ou APIs principais.

Instalar a ferramenta de vinculação staticcheck

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

Execute o Go Linter (staticcheck) no diretório raiz do projeto.

 staticcheck

Verificar a saída

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

O erro ocorre porque http.ListenAndServe() aceita uma string, e o código atual usa Sprintf sem transmitir variáveis para a string.

Confira o status de saída do comando.

echo $?

Nesse caso, como o comando resultou em um erro, o status de saída será 1 ou maior. Esse é um método que pode ser usado em um pipeline de CI/CD para determinar o sucesso/falha da ferramenta.

Edite o arquivo main.go e corrija o código:

• Comente a linha abaixo de LINTING - Step 1 no método main() adicionando barras inclinadas iniciais(//).
• Remova os comentários das duas linhas diretamente abaixo de LINTING - Step 2 no método main(), removendo os caracteres de barra invertida.

Execute staticcheck novamente no diretório raiz do projeto.

staticcheck

O comando não deve retornar nenhum resultado (ou seja, uma linha vazia).

Inspecione o status de saída do comando.

  echo $?

Nesse caso, como o comando não resultou em um erro, o status de saída será zero.

4. Teste estático de segurança de aplicativos

AST/Static security testing: oferece análise estática de código em busca de vulnerabilidades e pontos fracos comuns ( CWEs, na sigla em inglês).

Instalar a ferramenta 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}

Executar gosec com o arquivo de política no código-fonte

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

A saída será semelhante a esta:

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

A ferramenta identificou um possível problema: Potential hardcoded credentials

5. Verificação de licença

As licenças são importantes para a segurança porque podem exigir legalmente que você exponha o código-fonte que talvez você não queira expor. O conceito é chamado de licenças copyleft, que exigem que você exponha o código-fonte se usar dependências com essas licenças.

Instalar 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

Criar o arquivo binário

go build

Executar a verificação de licença com o arquivo de política atual que não permite licenças "BSD-3-Clause"

golicense policies/license-policy.hcl hello-world

OBSERVAÇÃO: isso vai falhar com uma saída semelhante:

 🚫 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

Modifique o arquivo de política policies/license-policy.hcl para mover a "BSD-3-Clause" da lista deny para a lista allow.

Executar a verificação de licença novamente

golicense policies/license-policy.hcl hello-world

OBSERVAÇÃO: isso deve funcionar com uma saída semelhante:

    ✅ 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

Para uso em produção, esses comandos (e outras ferramentas destinadas ao código-fonte) precisam ser incorporados a um pipeline de CI/CD.

6. Parabéns

Parabéns, você concluiu o codelab.

O que você aprendeu

• Ferramentas e técnicas para proteger o código-fonte

—

Última atualização: 23/03/23