Do ponto de vista do ciclo de vida de desenvolvimento de software (SDLC), a segurança é o aspecto mais importante dos negócios, pois as vulnerabilidades de segurança representam riscos para organizações grandes e voltadas para o usuário. Como resultado, as empresas investem pesadamente em tornar a segurança de software uma prioridade.

Ser uma empresa ou equipe centrada na privacidade pode agregar benefícios excepcionais como um todo. Os clientes valorizam os recursos de segurança de software que a empresa está desenvolvendo e aprimorando tanto quanto a usabilidade. Mas alcançar o marco requer consideração cuidadosa com implicações estritas nas melhores práticas e diretrizes de segurança SDLC.

O SDLC contém pontos de verificação de segurança para proteger a confidencialidade, disponibilidade e integridade do sistema geral e dos dados contidos nele. O SDLC mesclado com o modelo de maturidade de software OWASP (OWASP SAMM) pode ajudar a formular e implementar um roteiro estratégico em toda a empresa para segurança de aplicativos.

O que é a Cadeia de Suprimentos de Software?

A cadeia de suprimentos de software é uma disciplina que abrange equipes (internas e externas), metodologias, ferramentas e práticas recomendadas para trazer um artefato de software ao vivo, desde o design até a implantação.

Nos últimos tempos, os serviços e experiências digitais mais inovadores e disruptivos foram desenvolvidos usando software de código aberto por equipes remotas.

As bibliotecas de código aberto atraem desenvolvedores com seus recursos brilhantes, permitindo que os engenheiros aumentem o desenvolvimento, reduzindo o tempo de lançamento no mercado e as implicações de custo.

Mas surgem falhas e complicações no uso de software de código aberto devido à falta de controle sobre o código-fonte e lançamentos de recursos ao longo do tempo com patches, e eles trazem o risco de ataques à cadeia de suprimentos de código aberto .

Código desenvolvido inadequadamente com segredos embutidos em código e infraestrutura com arquitetura vaga está sujeito a ataques frequentes.

Vulnerabilidades mais populares

Vulnerabilidades de software são predominantes em organizações de todos os níveis. As empresas iniciantes têm maior probabilidade de serem vítimas de tais ataques, pois se concentram em trazer novos recursos para o mercado em prazos apertados. Infelizmente, essas exposições não chegam às manchetes para conscientizar a comunidade de tecnologia. Vamos discutir alguns dos incidentes históricos mais difundidos e impactantes.

Em determinado momento, as últimas notícias do ataque contra a SolarWinds abalaram o mundo da tecnologia. O evento tornou-se um excelente exemplo dos perigos de práticas de segurança inadequadas.

A catástrofe surgiu quando um estagiário não conseguiu configurar uma senha complexa. Os invasores se infiltraram no sistema SolarWinds por meio de uma combinação de senha fraca usando um método chamado pulverização de senha e conseguiram enviar malware por meio de um backdoor para todas as empresas dependentes. O ataque à cadeia de suprimentos foi baseado em identidade, o que atualizou o servidor de atualização da SolarWinds.

Aplicar políticas de senha fortes no sistema com camadas de segurança adicionais, como MFA, poderia ter evitado o desastre.

Um incidente semelhante ocorreu na autoridade de certificação do governo do Vietnã. Os invasores contornaram o firewall do site e inseriram arquivos de instalação adicionais nos aplicativos de instalação do VGCA, que são aplicativos voltados para o cliente oferecidos pelo VGCA para a oferta de assinatura digital.

A atividade geral foi bem-sucedida porque os invasores encontraram uma lacuna no design do site, pois o design geral era um pouco falho. O ataque backdoor era evitável com restrições rígidas de firewall, controles de acesso e permissões privilegiadas.

Para outro exemplo de como as vulnerabilidades podem prejudicar um sistema, vejamos os Bitcoins. Bitcoins podem ser facilmente expostos e roubados se o provedor de serviços não cumprir as diretrizes de segurança.

A Copay, uma carteira Bitcoin, sofreu um ataque na cadeia de suprimentos quando um aplicativo móvel que hospeda a carteira bitcoin teve um bug. O bug na arquitetura surgiu por meio da vulnerabilidade do pacote de um gerenciador de pacotes (NPM) de nó de ferramenta Javascript de software livre. Essa versão com bug foi tornada pública e permitiu que o hacker alterasse os aplicativos para carregar o código refatorado e obter acesso à biblioteca JS.

O bug poderia ter sido detectado e corrigido com ferramentas de verificação de vulnerabilidade no controle de versão e pipeline de implantação.

Peças móveis para gerenciar a cadeia de suprimentos de software

Um projeto bem articulado que segue documentação sólida, segurança cibernética, remediação de riscos e melhores práticas de gerenciamento elimina vulnerabilidades potenciais e aumenta a segurança da cadeia de suprimentos de software. As organizações devem adaptar os princípios de engenharia “seguro por design” e uma estratégia shift-left para estabelecer uma cadeia de ferramentas DevSecOps abrangente.

Etapa 1: alfabetização de codificação segura

Principalmente, as empresas devem adotar programas exclusivos de aprendizado e desenvolvimento em segurança e gerenciamento de riscos. À medida que as equipes de desenvolvimento correm para melhorar suas habilidades técnicas, um objetivo comum que as empresas devem compartilhar é maneiras de ajudar os desenvolvedores a se tornarem defensores da segurança.

Avaliações de vulnerabilidade de aplicativos e cursos de segurança são necessários para manter os engenheiros alinhados com as metas de negócios.

Estágio 2: Modelagem de Ameaças

Identificar os riscos de segurança antes que o desenvolvimento e as operações se atualizem é essencial. Este estágio garante que a estratégia geral de design e desenvolvimento esteja alinhada com os padrões de segurança organizacional.

A modelagem de ameaças apresenta às organizações uma abordagem estruturada para identificar, analisar, avaliar e mitigar riscos nos estágios iniciais de desenvolvimento. Os modelos de ameaças são promissores em relação à segurança, permitindo que desenvolvedores e arquitetos pensem do ponto de vista do invasor, permitindo que eles planejem e projetem um sistema seguro.

<?xml version="1.0" encoding="utf-8"?>
<KnowledgeBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <Manifest name="Basic threat modelling design" id="5d3b996b-bac2-8cf6-3b39-617bb67bf042" version="4.1.0.11" author="TwC MSEC" />
 <ThreatMetaData>
   <IsPriorityUsed>true</IsPriorityUsed>
   <IsStatusUsed>false</IsStatusUsed>
   <PropertiesMetaData>
     <ThreatMetaDatum>
       <Name>Title</Name>
       <Label>Title</Label>
       <HideFromUI>false</HideFromUI>
       <Values>
         <Value />
       </Values>
       <Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
       <AttributeType>0</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>UserThreatShortDescription</Name>
       <Label>Short Description</Label>
       <HideFromUI>true</HideFromUI>
       <Values>
         <Value>Threat modeling is critical and mandate phase in secure software development</Value>
       </Values>
       <Id>ac0f9ea8-aed5-4d95-4ce9-6787124d7b48</Id>
       <AttributeType>1</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>UserThreatDescription</Name>
       <Label>Description</Label>
       <HideFromUI>false</HideFromUI>
       <Values>
         <Value />
       </Values>
       <Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
       <AttributeType>0</AttributeType>
     </ThreatMetaDatum>
     <ThreatMetaDatum>
       <Name>Priority</Name>
       <Label>Priority</Label>
       <HideFromUI>true</HideFromUI>
       <Values>
         <Value>High</Value>
         <Value>Medium</Value>
         <Value>Low</Value>
       </Values>
       <Description>Priority</Description>
       <Id>ac0f9ea8-aed5-4d95-4ce9-617bb67bf042</Id>
       <AttributeType>1</AttributeType>
     </ThreatMetaDatum>
   </PropertiesMetaData>
 </ThreatMetaData>
 <GenericElements>
   <ElementType>
     <Name>Threat modeling Process</Name>
     <ID>GE.P</ID>
     <Description>General approach to define a threat model</Description>
     <ParentElement>ROOT</ParentElement>
     <Image>Image_ref</Image>
     <Hidden>false</Hidden>
     <Representation>Ellipse</Representation>
     <StrokeThickness>0</StrokeThickness>
     <ImageLocation>Centered</ImageLocation>
     <Attributes>
       <Attribute>
         <Id>002864b3-9a4e-4d21-8a4d-8aea1d2e3056</Id>
         <IsInherited>false</IsInherited>
         <IsOverrided>false</IsOverrided>
         <Name>codeType</Name>
         <DisplayName>Code Type</DisplayName>
         <Mode>Dynamic</Mode>
         <Type>List</Type>
         <Inheritance>Virtual</Inheritance>
         <AttributeValues>
           <Value>Not Selected</Value>
           <Value>Managed</Value>
           <Value>Unmanaged</Value>
         </AttributeValues>
       </Attribute>
     </Attributes>
   </ElementType>
 </StandardElements>
 </KnowledgeBase>

O código deve ser obrigatório para revisão de código por pares. A habilitação de revisões diretas e por e-mail permite que as equipes de desenvolvimento detectem bugs e defeitos durante o estágio inicial do desenvolvimento.

Atrasos e falhas de vulnerabilidade podem chegar ao código mesmo com considerações cuidadosas e esforços manuais. As falhas mais comuns incluem se há alguma construção de programação ausente, o código geral está em conformidade com os padrões de segurança e o código passa nas verificações de lint e dica de tipo.

As revisões de código assistidas por ferramentas são menos propensas a erros e evitam riscos de vulnerabilidade. O GitHub pode provar ser uma ferramenta confiável e eficiente para auditorias e revisões de código em movimento, com o controle de versão como uma vantagem adicional.

Estágio 4: Digitalização por meio de ferramentas automatizadas

Automatizar a revisão do código antes de mesclar no mestre é de extrema importância. Deixar de passar nas verificações predefinidas destaca os problemas no código e permite um ciclo de feedback para os desenvolvedores refatorarem e protegerem a base de código geral.

WhiteSource para desenvolvedores, Codacy e Codecov são ferramentas de revisão automatizadas disponíveis no mercado GitHub para integrar-se rapidamente à sua base de código e atender aos requisitos de pilha de tecnologia. Essas ferramentas usam a abordagem shift-left para digitalização e indexação de código aberto de todos os repositórios GitHub existentes.

Estágio 5: verificação de código estático e teste de segurança

Automatizar a depuração e as revisões de código, ignorando a execução por meio de pipelines, pode ser proveitoso durante os estágios de criação e implantação. Ferramentas avançadas de automação de pipeline, como Jenkins, são carregadas com uma ampla variedade de plug-ins de revisão de código.

Plug-ins de revisão de código estático , como FindBugs, realizam revisão e análise de código executando verificações e lógica predefinidas, retornando um arquivo de saída. Jenkins pode analisar o arquivo de saída do trabalho, destacar os erros e listar os avisos encontrados seguindo uma abordagem de cima para baixo no nível do diretório do código e apresentando um resumo detalhado da análise geral graficamente.

Exemplo de código:

trigger:
 branches:
   include:
   - feature
   - main
 paths:
   include:
   - src/*
   - tests/*

pool:
 Image: 'centos/latest'

jobs:
- job: codereview
 displayName: review and report

 steps:

 - checkout: self
   lfs: true

 - task: UsePythonVersion@0
   displayName: 'Set Python version to 3.9'
   inputs:
     versionSpec: '3.9'

 - script: pip3 install --user -r requirements.txt
   displayName: 'Installing required dependencies'

 - script: |
     python -m behave --junitxml=./validation_test-checks.xml
   displayName: 'Running behave tests'

 - task: PublishBehaveResults@1
   displayName: 'bumping out behave test results'
   condition: passOrFail()
   inputs:
     testResultsFiles: '**/validation_test-*.xml'
     testRunTitle: 'Publish behave test results for Python $(python.version)'

As vulnerabilidades da cadeia de suprimentos de software são feras inevitáveis. Quando ignorados, eles podem derrubar todo um sistema, impactando tanto os negócios quanto a reputação. O SDLC abrange várias técnicas e conjuntos de ferramentas para tornar a segurança um marco principal da jornada do software.

A fase geral de desenvolvimento deve seguir os estágios destacados acima, começando pela alfabetização de segurança, modelagem de ameaças, revisão de código de pares, verificações de código automatizadas e verificação de código estático e teste de segurança.

Dos relatórios da Infosec: Muito está surgindo na Infosec todos os dias, o que é difícil de acompanhar. Junte-se ao nosso boletim semanal para obter todas as últimas tendências da Infosec na forma de 5 artigos, 4 tópicos, 3 vídeos, 2 repositórios e ferramentas do GitHub e 1 alerta de trabalho GRATUITAMENTE!