Requisitos de segurança de código aberto das normas PCI: como estar em conformidade?

Com o uso cada vez maior de segurança de código aberto no desenvolvimento de software moderno, é urgente garantir que o código aberto seja usado com segurança. No entanto, a segurança de código aberto ainda não é uma prática generalizada: um relatório recente da Snyk constatou que 37% dos desenvolvedores de código aberto não realizam nenhum tipo de teste de segurança durante o processo de integração contínua (CI)! O crescimento do código aberto, combinado com a defasagem das normas de segurança, levou muitos órgãos reguladores e entidades de fiscalização do setor a adotar regras mais rigorosas e claras sobre como proteger aplicações que incluem código aberto.

PCI assume a responsabilidade pelo código aberto

Em janeiro de 2019, o Conselho de Normas de Segurança do Setor de Cartões de Pagamento lançou o PCI Software Security Framework (SSF), com foco na segurança de aplicações. Também foi incluído o padrão Secure Software Lifecycle (SLC), uma seção do PCI Software Security Framework que define requisitos de segurança e procedimentos de avaliação para que fornecedores de software validem como gerenciam a segurança de softwares de pagamento durante todo o ciclo de vida.

(Observação: o novo framework está substituindo as diretrizes atuais do PCI Payment Application Data Security Standard [PCI PA-DSS], que será descontinuado nos próximos anos.)

Na Snyk, ficamos felizes em ver o PCI reconhecer a importância de proteger componentes de código aberto no código e incentivar as organizações a “deslocar para a esquerda” a responsabilidade pela segurança ao longo do ciclo de vida do desenvolvimento de software. Quanto mais cedo incorporarmos as práticas recomendadas de segurança ao ciclo de vida do software, especialmente no caso do código aberto, mais seguras serão nossas aplicações.

Dito isso, como acontece com muitos outros frameworks de conformidade, pode ser difícil entender e implementar novas regras. Por isso, queremos explicar um pouco melhor as novas regras de conformidade do PCI e mostrar como atender especificamente aos requisitos relacionados a código aberto no padrão atualizado.

Quem deve se preocupar com as atualizações do PCI?

O PCI Secure Software Standard (e o padrão SLC que o fundamenta) se aplica a softwares de pagamento vendidos, distribuídos ou licenciados a terceiros para realizar transações de pagamento. O PCI Software Security Framework é especialmente relevante para fornecedores que desenvolvem aplicações de processamento de pagamentos e para quem vende essas soluções a terceiros. A atualização destaca que tanto as lideranças de segurança quanto as equipes de engenharia devem assumir a responsabilidade por atender às normas de conformidade.

Há outras regras das diretrizes PCI-DSS que empresas que aceitam pagamentos precisam observar, mas os padrões que abordaremos nesta publicação se aplicam diretamente aos desenvolvedores de software.

Chega de fazer uma vez e pronto: a chave é a continuidade

Talvez o aspecto mais importante do novo padrão seja o conceito de “segurança contínua de aplicações”. O padrão exige que as organizações monitorem continuamente as vulnerabilidades e as defesas, além de se adaptarem quando as ameaças mudarem. Também exige que testem continuamente os controles de segurança das aplicações e comprovem que eles não se enfraqueceram nem perderam a eficácia com o tempo. É uma exigência alta — e isso é bom. Ela força as organizações a tratar a segurança como parte do processo de CI/CD, e não como algo deixado para depois.

O que motivou as atualizações do PCI? Por que agora?

Afinal, por que esses padrões foram atualizados? Como mencionamos na introdução, o desenvolvimento de software evoluiu naturalmente ao longo dos anos, e os padrões PCI atualizados são uma resposta bem pensada a essa evolução, renovando também a abordagem à segurança de software. Em especial, cada vez mais estratégias de desenvolvimento de software dependem de componentes de código aberto. Por isso, foi necessário acrescentar requisitos e controles aplicáveis a eles. No nosso relatório State of Open Source Security 2019, compartilhamos algumas estatísticas sobre o tema, incluindo estes dados reveladores:

• Houve um aumento de 88% nas vulnerabilidades em bibliotecas de aplicações em dois anos81% dos entrevistados acreditam que os desenvolvedores devem ser responsáveis pela segurança, mas não têm recursos adequados para issoQuem mantém projetos de código aberto quer garantir a segurança, mas 70% não têm as habilidades necessárias

Além da expansão do desenvolvimento de código aberto, muitas organizações agora integram ferramentas de segurança ao pipeline de DevOps, e essas ferramentas se tornaram mais proativas e eficazes com o tempo. Por isso, garantir uma segurança robusta em ciclos contínuos de desenvolvimento e integração é necessário e, o que é melhor, mais viável do que nunca.

O papel do código aberto nas novas atualizações do PCI

Vamos analisar em detalhes os aspectos das novas regras do PCI que se aplicam a componentes de software de código aberto. (Você também pode consultar os padrões completos aqui.)

1. Responsabilidade das lideranças de segurança

O texto: Seção 1.1 — A alta liderança do fornecedor deve atribuir formalmente a uma pessoa ou equipe a responsabilidade por garantir a segurança dos produtos e serviços do fornecedor.

O que isso significa para você: as lideranças de segurança de grandes organizações devem assumir a responsabilidade pela segurança e fazer as mudanças necessárias nos processos de desenvolvimento e nas ferramentas para atender aos requisitos atualizados do PCI.

Como a Snyk pode ajudar: as lideranças de segurança já têm muitas prioridades. A Snyk simplifica o processo de adequação aos novos padrões PCI ao oferecer visibilidade sobre dependências de código aberto e riscos de licenças, permitindo que sejam tratados de forma adequada e oportuna.

2. O papel dos desenvolvedores

O texto: Seção 1.2.a — As pessoas (incluindo profissionais terceirizados) envolvidas no design, desenvolvimento, teste e manutenção dos produtos e serviços do fornecedor devem receber responsabilidades e atribuições para garantir que o software seja projetado e mantido de acordo com a estratégia de segurança do fornecedor e todos os requisitos de segurança aplicáveis.

O que isso significa para você: os novos requisitos mencionam especificamente a participação e a responsabilidade dos desenvolvedores (“profissionais de desenvolvimento de software”) nas etapas definidas para alcançar a conformidade.

Como a Snyk pode ajudar: a abordagem da Snyk, que prioriza os desenvolvedores, incentiva a adoção fácil das práticas recomendadas de segurança. A Snyk ajuda os desenvolvedores a encontrar e corrigir vulnerabilidades como parte do processo de desenvolvimento de software que já utilizam. A Snyk também facilita a criação de uma solicitação de pull para correção com um clique e a automação de correções no Git, para que os desenvolvedores possam resolver rapidamente as vulnerabilidades identificadas.

3. Componentes de código aberto

O texto: Seção 3.2.b — Quando componentes de software de código aberto forem utilizados no software, o avaliador deverá examinar as evidências fornecidas, incluindo a documentação do processo e os resultados da avaliação, para confirmar que esses componentes são gerenciados.

O que isso significa para você: o código aberto pode ser uma grande vantagem no desenvolvimento de software, mas é necessário fazer a devida avaliação antes de incluir qualquer componente de código aberto na sua aplicação. A organização deve:

• manter um inventário de todos os componentes de código aberto utilizados, incluindo imagens de contêineres

• desenvolver um processo maduro para analisar e mitigar vulnerabilidades

• monitorar vulnerabilidades em componentes de código aberto

• implementar uma estratégia de aplicação de patches

Como a Snyk pode ajudar: a Snyk permite que os clientes mapeiem as dependências das aplicações, identifiquem vulnerabilidades existentes e testem continuamente novas vulnerabilidades em uma abrangente base de dados. A Snyk oferece recursos completos para aplicar patches e corrigir problemas, com solicitações de pull automatizadas que agilizam a triagem e a correção. Na prática, a Snyk automatiza o processo de conformidade com a seção 3.2.b, reduzindo o trabalho manual e o tempo dedicado à conformidade. Com a Snyk, as equipes podem demonstrar que implementaram etapas de verificação, correção e monitoramento de possíveis vulnerabilidades em componentes de código aberto.

Use a conformidade com o PCI para incentivar a segurança desde o início

À medida que as organizações continuam a integrar a segurança desde o início, surgem novos desafios e oportunidades. As atualizações dos requisitos de conformidade do PCI fazem sentido diante da realidade dos processos atuais de desenvolvimento de software e da ampla adoção do código aberto. Embora os requisitos possam parecer rigorosos à primeira vista, atendê-los ajuda sua organização a aumentar a segurança e reduzir o perfil geral de risco — um esforço que vale a pena, mesmo além dos benefícios da conformidade.

O maior desafio para a maioria das organizações ao atender aos novos padrões PCI será implementar ferramentas de segurança específicas para código aberto pela primeira vez, já que muitas ainda não contam com elas. Incorporar as práticas recomendadas de segurança de código aberto ao pipeline de CI/CD tornará a segurança uma parte natural do processo de desenvolvimento, em vez de um fardo no fim ou de uma corrida para agir quando novas vulnerabilidades forem divulgadas publicamente.

Para descobrir como a Snyk pode ajudar você a atender com facilidade aos novos padrões de conformidade PCI para código aberto, os desenvolvedores podem começar a usar a Snyk gratuitamente hoje mesmo.