SAST (Static Application Security Testing) é um scan de verificação de vulnerabilidades em códigos estáticos, ou seja, não depende que a aplicação seja em execução para fazer a verificação de vulnerabilidades. Esse scanner pode ser executado isoladamente, no início do pipeline de CI ou como um plug-in na IDE durante a codificação. No post sobre SBOM comentei que “algumas empresas podem conter até 90% do código bibliotecas opensource em sua composição (20% sendo o framework, 70% bibliotecas importadas para problemas simples)“, portanto devemos concentrar o SAST exatamente na parte de código onde os desenvolvedores atuam diretamente, que é o código proprietário.

O SAST garante que problemas de segurança como salvar uma senha em texto claro dentro do código fonte de uma aplicação sejam detectados antes desse código ser publicado em produção. Além disso é possível garantir se os padrões de boas práticas de programação sejam seguidas, portanto o SAST é um scan que depende da linguagem de programação que esteja sendo utilizada naquele projeto. Isso deve ser levado em consideração na hora de escolher uma ferramenta para fazer essa verificação.

Um dos objetivos do SAST é auxiliar na detecção de possíveis problemas desde os estágios iniciais do processo de desenvolvimento, por isso que ele deve ser integrado como plug-in da IDE ou na pipeline de CI. Quanto mais precoce a correção de vulnerabilidades, mais simples e barata se torna essa etapa. Além disso, aumenta a conscientização do desenvolvedor sobre possíveis problemas, ajudando-os a evitar outros problemas relacionados. Essas práticas estão relacionada ao “Shift-Left”, tema que será abordado em outro post.

Algumas vantagens do SAST:

  • Detecte cedo e corrija cedo: Como o SAST pode ser realizado até mesmo dentro da IDE, o processo de correção ocorre bem no início do processo de fatoração do código, evitando mais problemas maiores;
  • Exatidão na localização do problema: O SAST funciona no código estático, o relatório irá apontar qual arquivo, em qual linha e coluna um possível problema foi detectado. Dependendo da aplicação que foi utilizada, é possível fazer uma relação com CWEs, CVE ou OWASP Top 10. A correção se torna mais eficiente dessa forma;
  • Fácil automação: A execução do código SAST não precisa de nenhum tipo de interação, portanto é fácil fazer a automatização do processo. Tenha em mente que configurar corretamente a ferramenta é um outro processo;
  • Velocidade do Scan: Basicamente, as ferramenta SAST irão ler arquivos. Não é necessário validações e interações como é o caso do DAST. Com isso, a velocidade de SCAN é considerada rápida.


Para ter sucesso no scan, é necessário atenção em alguns pontos:
 
  • Escolha a ferramenta correta: O SAST verifica o código fonte de uma aplicação, por tanto existe uma linguagem de programação atrelada ao código, assim como existem melhores práticas para essa linguagem. Por tanto, ao escolher uma ferramenta, verifique se ela tem suporte para a linguagem do seu projeto e se ela tem bibliotecas, scripts, padrões de mercado, melhores práticas para a linguagem que você quer verificar. Algumas ferramentas têm a opção de importar essas opções tanto da comunidade como personalizadas;
  • Saiba onde fazer o Scan: Foque o SAST no código proprietário, ou seja, no que você e sua equipe de desenvolvedores estão de fato codificando. Qualquer parte da sua aplicações que seja de terceiros, como bibliotecas, faça utilizando outras ferramentas próprias para isso. Recomendo a leitura do post sobre SCA e o outro sobre SBOM;
  • Adicione o SAST na pipeline: Automatize o scan para que possa focar na resolução do problema e não na ferramenta em si;
  • Atenção aos Falsos-Positivos: Toda ferramenta automatizada pode trazer falsos-positivos, portanto atenção à cada ponto do relatório que a ferramenta ou equipe de segurança irá apresentar para a equipe de desenvolvimento. É importante identificar o que de fato é um falso-positivo e o que de fato é uma vulnerabilidade.

Algumas ferramentas SAST:

 

A cadeia de suprimentos, também conhecida como Supply Chain Management (SCM), é o conjunto de atividades que envolvem a produção, armazenamento e transporte de produtos ou serviços. Isso inclui a compra de matérias-primas, controle de estoque e o transporte do produto até o cliente final, definição dada no artigo da Voitto.

Certo, mas qual seria a cadeia de suprimentos de uma aplicação? Como definir esse conceito para a construção de um software?  Fácil! Todo o processo de construção de uma aplicação faz parte dessa cadeia, afinal teremos uma entrega a um cliente final da mesma forma.

Para fazer uma analogia, vamos supor uma empresa XPTO que fabrique “Camisas Sociais de Luxo”. Essa empresa XPTO terá que selecionar as melhores matérias primas,  como tecidos de alta qualidade. O maquinário que irá fazer o corte e costura dessas camisas devem ser específico para essa finalidade, assim como os funcionários devem ser treinados para manusear essa matéria prima e esses equipamentos. Outro ponto que pode ser observado é o transporte dessas camisas ao lojista que irá vendê-las. As camisas não podem sair da fábrica de uma forma e chegar de outra forma. Além disso, o próprio lojista deve ser qualificado para oferecer a melhor experiência para o cliente final. Todo esse processo é monitorado, verificado e medido para garantir a qualidade ofertada ao cliente final.

Para um software, devemos ter os mesmos cuidados, porém trazendo para a realidade da construção de uma aplicação. Desde a escolha da linguagem de programação, fazer a modelagem de ameaças, utilizar as melhores práticas de desenvolvimento seguro, scans de vulnerabilidades automatizados, proteção das aplicações de CI/CD, assim como a proteção da rede e dos ambientes onde serão feitos os deploys. Lembrando que isso é apenas um exemplo, o nível das escolhas pode variar bastante como até mesmo a escolha dos fabricantes dos chips, qual provedor de cloud, entre outros detalhes.

O NIST (National Institute for Standards and Technology) define o ataque à cadeia de suprimentos como “Ataques que permitem ao atacante implantar ou usar vulnerabilidades inseridas antes da instalação para infiltrar dados ou manipular hardware, software, sistemas operacionais, periféricos ou serviços de tecnologia da informação em qualquer ponto durante o ciclo de vida do desenvolvimento do software.” Na relatório “2022 AppSec Trend Report” da MicroFocus, a segurança da cadeia de suprimentos é o primeiro tópico a ser abordado. Os ataques ao log4j e à Solarwinds também são mencionados como exemplos nesse relatório.

A ENISA (European Union Agency for Cybersecurity) publicou um relatório onde ela classifica que o ataque à cadeia de suprimentos tem uma combinação de dois alvos: O primeiro é fornecedor que é usado para atacar o alvo para obter acesso aos seus ativos e o segundo é o cliente final, ou outro fornecedor, que utiliza o software ou hardware desse fornecedor.

Além desses dos alvos, a ENISA também definiu quatro características principais em um ataque à cadeia de suprimentos:

  1. Técnicas de ataque usadas para comprometer o fornecedor;
  2. Ativos do fornecedor visados ​​no ataque;
  3. Técnicas de ataque usadas para comprometer o cliente;
  4. Ativos do cliente visados ​​no ataque;

1 – “Técnicas de ataque usadas para comprometer o fornecedor” se preocupam como o ataque ocorreu e não como foi utilizado para fazer o ataque. Alguns exemplos são: Engenharia Social, Ataque de Força Bruta, OSINT, Exploração de Vulnerabilidade de um Software;

2 – “Ativos do fornecedor visados ​​no ataque” referem-se a qual foi o alvo do ataque ao fornecedor. Os exemplos são: Bibliotecas importadas ao código, Código proprietário, Processos ou Pessoas;

3 – “Técnicas de ataque usadas para comprometer o cliente” faz referência como o cliente foi atacado: “Trusted Relationship” [T1199], Phishing [T1566], “Drive-by Compromise” [T1189] Ataque ou Modificação Física;

4 – “Ativos do cliente visados ​​no ataque” é o principal e final alvo do ataque, também sendo a razão do ataque. Geralmente, mais de um cliente é afetado por esses ataques. Os exemplos são: Dados profissionais ou pessoais, Ataques Financeiros, Infraestrutura de Rede (DDOS, SPAM…).

Depois de fazer o levantamento dos dados, basta cruzá-los para compreender como o ataque foi realizado com sucesso.

Como exemplo, vamos verificar como foi o ataque ao CodeCov:

  1. O processo de criação do container Codecov tinha um bug que estava presente nos containers implantados online;
  2. Os invasores acessaram o container e obtiveram as credenciais do Codecov;
  3. Eles então modificaram o script bash do Codecov;
  4. E esse novo script que foi modificado, foi atualizado nos clientes;
  5. O script bash malicioso exfiltrava as credenciais do cliente para o invasor;
  6. O invasor utilizava as credenciais para acessar os dados dos clientes.

Referenciando as quatro características, podemos utilizar os dados da seguinte forma:

FORNECEDOR CLIENTE
Técnicas de ataque usadas para comprometer o fornecedor Ativos do fornecedor visados ​​no ataque Técnicas de ataque usadas para comprometer o cliente Ativos do cliente visados ​​no ataque
Explorar Vulnerabilidade de Configuração; Código “Trusted Relationship” [T1199]; Software


Pode ser complexo garantir a segurança da cadeia de suprimentos, porém é muito importante ter em mente que deve esse tipo de ataque está ocorrendo com mais frequência. Adotar medidas de segurança, é um processo de amadurecimento e nesse caso pode ser implementado por equipes em paralelo.

 

Referências:

https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks
https://debricked.com/blog/software-supply-chain-attacks-part-one/
https://www.cyberark.com/resources/blog/breaking-down-the-codecov-attack-finding-a-malicious-needle-in-a-code-haystack
https://community.microfocus.com/cyberres/b/sws-22/posts/appsec-trends-securing-the-software-supply-chain

Ao som de: Opeth – In My Time Of Need

O “Software Bill of Materials” (SBOM – Lista de Materiais de Software), fazendo um paralelo, é o equivalente, em um software, a lista de ingredientes nas embalagens de alimentos. Pessoas alérgicas a algum componente dos ingredientes do produto podem ter essa informação nessa lista impressa na embalagem.

Esses ingredientes podem conter um componente de terceiro, com a caseína que compõe o leite, por exemplo, e assim o consumidor alérgico à caseína pode evitá-lo por saber que o leite é um dos ingredientes. Mas as SBOMs vão além de uma simples lista de ingredientes.

Em termos de software, um componente de terceiros é uma dependência e cada dependência pode ter subdependências. Esses componentes, dependências e subdependências podem incluir projetos de software de código aberto, código proprietário, APIs, estruturas de linguagem de programação e bibliotecas de software. 

O conceito SBOM surgiu pela primeira vez no final da década de 1990 como uma ferramenta local, limitada a equipes internas de desenvolvimento.
Em 2007, foi ampliado para permitir rastreamento e conformidade com licenciamento de software de terceiros.
Em 2018, grupos de trabalho públicos/privados organizados fora da NTIA, coordenados pelo Dr. Alan Friedman, começaram a trabalhar seriamente para expandir e desenvolver SBOMs em uma ferramenta útil de segurança cibernética.
Julho de 2021, a Administração Nacional de Telecomunicações e Informações (NTIA) emitiu orientações definitivas em um relatório detalhando os elementos mínimos para um SBOM.Alguns dos pontos dessa orientação são:

  • Qual versão foi usada?
  • De onde foi originado o componente?
  • Quais os relacionamentos deste componente?
  • Qual o nome do autor e do fornecedor?

A lista completa de elementos está disponível na Administração Nacional de Telecomunicações e Comunicações do Departamento de Comércio (NTIA).

 

Source: https://www.erp-information.com/wp-content/uploads/2022/06/sbom-format.png

 

Isso tudo pode ser muito complicado para uma empresa catalogar. Para ajudar essa organização, existem dois padrões mais conhecidos: SPDX e CycloneDx

SPDX é um padrão aberto para comunicação de informações SBOM, incluindo proveniência, licença, segurança e outras informações relacionadas e é um padrão internacional reconhecido pela ISO/IEC 5962:2021
CycloneDX , uma ferramenta SBOM originalmente criada por Steve Springett e agora uma iniciativa OWASP (Open Web Application Security Project).

Quando as vulnerabilidades de software são descobertas, elas geralmente são encontradas em componentes que são dependências de outros aplicativos de software. Saber se uma organização está em risco devido a um componente de terceiros é um desafio comumente chamado de Risco da cadeia de suprimentos (Supply Chain). Os ataques à integridade da cadeia de suprimentos tem se tornado mais comuns, causando prejuízos de bilhões de dólares como foi o caso dos ataques as empresas Solarwinds e Codecov.

Uma proposta para a melhor proteção da cadeia de suprimentos é a adoção da Supply chain Levels for Software Artifacts (SLSA ou SALSA) que é um framework que garante segurança a cadeia de suprimentos (assunto para um outro post mais detalhado).

Muitas organizações enfrentam o desafio de saber se estão em risco devido a uma vulnerabilidade de software. Quando a vulnerabilidade “Heartbleed” foi divulgada em 2014 (CVE-2014-0160), todos os aplicativos e serviços que dependiam do OpenSSL como dependência precisavam ser atualizados.
O mesmo tipo de risco também foi exposto pela vulnerabilidade de software de código aberto Log4J (CVE-2021-44228) que foi divulgada em dezembro de 2021. Mesmo depois que um componente ou biblioteca de origem é corrigido pelo projeto original, cabe ao fornecedor mantenedor do componente, e de cada usuário final corrigir a vulnerabilidade atualizando o componente.

Em um cenário onde os softwares de algumas empresas podem conter até 90% do código bibliotecas opensource em sua composição (20% sendo o framework, 70% bibliotecas importadas para problemas simples), é de extrema importância saber quais componentes estão sendo utilizados, além das suas subdependências. Essa prática é utilizada para ajudar a entender e mitigar vulnerabilidades conhecidas no código, economizando tempo e custos.
Os SBOMs também ajudam os departamentos jurídicos e de conformidade a identificar o histórico de licenças e os casos de uso permitidos para um código de terceiros, o que reduz qualquer uso indevido em potencial. Além disso, os SBOMs ajudam as equipes de segurança e forense a identificar o impacto no software após a descoberta de vulnerabilidades e exposições comuns (CVEs) recém-identificadas, que melhoram a capacidade das organizações de responder e corrigir.

Uma lista de aplicativos que podem gerar uma lista SBOM:

Microsoft SBOM Tool
Trivy
Syft
Opensbom Generator
CycloneDX
KubeClarity
FossID – Snyk
Mend

Ao som de: David Bowie – Moonage Daydream