Sobre como melhorar a segurança com Steve Wilson

Steve Wilson é o diretor de produtos da Contrast Security, com mais de 25 anos de experiência no desenvolvimento e comercialização de produtos em empresas de tecnologia multibilionárias, como Citrix, Oracle e Sun Microsystems. Neste AMA, Steve nos fala sobre segurança sem servidor, segurança de aplicativos no ecossistema JAVA, SBOMs e práticas recomendadas. Este tópico de Slogging de Mónica Freitas, Steve Wilson, Zach Taylor, Victor de Avila, Jack Boreham e Sara Pinto ocorreu no canal #amas oficial do slogging e foi editado para facilitar a leitura. Ei @channel, junte-se a mim para dar as boas-vindas ao nosso próximo convidado do AMA, Steve Wilson. Steve é atualmente o diretor de produtos da Contrast Security. Hoje sua equipe é responsável pela Engenharia, Gerenciamento de Produto e Design de Produto para todos os produtos. Steve tem mais de 25 anos de experiência no desenvolvimento e comercialização de produtos em empresas de tecnologia multibilionárias, como Citrix, Oracle e Sun Microsystems. Antes da Contrast, Steve foi vice-presidente de gerenciamento de produtos da Citrix Cloud, onde liderou a transformação dos produtos Citrix de locais tradicionais para SaaS.

Na Oracle, ele liderou a engenharia básica de uma linha de produtos de software de gerenciamento de sistemas de bilhões de dólares. Durante seu tempo na Sun Microsystems, Steve foi um dos primeiros membros da equipe que desenvolveu o sistema de programação de computador Java, o conjunto de ferramentas de desenvolvimento de software mais amplamente usado na história.

Sinta-se à vontade para perguntar a Steve qualquer coisa sobre:

Olá Steven Wilson! É muito bom ter você conosco! Você poderia começar nos contando um pouco sobre sua experiência e como você veio trabalhar com a Contrast Security?

Olá Mónica Freitas! É ótimo estar aqui. Gostaria de começar agradecendo ao HackerNoon por ter me juntado ao AMA deles e estou ansioso para responder às suas perguntas.

Sou o diretor de produtos da Contrast Security, líder em segurança de aplicativos que capacita os desenvolvedores a proteger enquanto codificam. Nossa plataforma fornece aos desenvolvedores soluções de segurança de autoatendimento para melhorar a eficiência em todo o ciclo de vida do desenvolvimento de software, ao mesmo tempo em que protege os aplicativos contra vulnerabilidades pré, durante e pós-produção. Aproveito meus mais de 25 anos de experiência em desenvolvimento e marketing de produtos para liderar minhas equipes responsáveis pela engenharia, gerenciamento de produtos e design de todos os produtos da Contrast.

2 curiosidades sobre mim:
- Sou faixa preta de segundo grau em Taekwondo.
- Eu gosto de tocar rock clássico no violão.

Sinta-se à vontade para me seguir no Obrigado, Mónica Freitas, fico feliz por falar como vim para a Contrast! Entrei há cerca de 18 meses, após passagens por grandes empresas como Citrix, Oracle e Sun Microsystems. Trabalhei como contribuidor individual e funções de gerenciamento em Engenharia e Gerenciamento de produtos, voltando aos meus dias como um dos primeiros membros da equipe Java no final dos anos 90. Fico feliz em responder a perguntas sobre curiosidades sobre Java/Sun, se as pessoas estiverem interessadas. 🙂 História rápida, porém, sobre como cheguei ao Contrast. Em minha função anterior, entrei em uma situação em que uma equipe de centenas de engenheiros foi completamente descarrilada por uma equipe de segurança que executava um produto ruim de "varredura de código". Isso gerou enormes dívidas técnicas para nós (que fomos obrigados a resolver), mas quase não levou a melhorias em nossa postura de segurança. Atrasou os cronogramas e criou uma enorme frustração. Juntando-me ao Contrast, percebi que havia uma maneira melhor de fazer isso! Olá Steve! Você pode explicar o que é serverless? Obrigado, Zach Taylor! Serverless é um daqueles termos que significam muitas coisas para muitas pessoas, então vamos detalhá-lo. Em essência, é um conjunto de tecnologias projetadas para tornar a computação do lado do servidor mais eficiente e simples. Um uso do termo é sobre a ideia de abstrair o conceito pesado de uma "máquina virtual" (como VMware) e, em vez de usar construções escaláveis e leves, como Docker Containers e Kubernetes. No entanto, acho que há um movimento muito mais interessante acontecendo dentro do Serverless... A maior revolução em 20 anos para a arquitetura de aplicativos é o Functions as a Service. O exemplo mais popular disso é o Amazon Web Services (AWS) Lambda - embora outras nuvens como Microsoft e Google tenham adicionado construções semelhantes. Da mesma forma que os Servlets Java foram uma grande melhoria na arquitetura da Web em comparação com o "CGI" anterior, as funções sem servidor podem ser 100 vezes mais rápidas e mais baratas do que as arquiteturas tradicionais. Essas funções não são divertidas o tempo todo, elas são mais "baseadas em eventos" e são executadas apenas quando necessário. Você os vê sendo usados em locais onde escalabilidade massiva e baixo custo são críticos. Aplicativos da Internet das Coisas (IoT) nos quais você pode enviar dados de milhares ou milhões de dispositivos de volta para um serviço de coleta de dados. Isso é realmente emocionante.

Isso é muito emocionante para os desenvolvedores! E quando você menciona a IoT, parece que ela abre as portas para muitos casos de uso diferentes.

Como a segurança sem servidor é diferente, digamos, da segurança tradicional de aplicativos?

Ótima pergunta, Zach Taylor! Existem muitas diferenças! No lado "positivo", você perde muitas coisas com as quais "não" pode se preocupar. Você não precisa se preocupar em ter um Sistema Operacional ou mesmo um AppServer que precisa de patch. Tudo isso "desaparece" embaixo de você. Algumas versões ainda existem em algum lugar, mas você não as vê ou gerencia. Isso é uma grande vantagem do ponto de vista da segurança! No entanto, do lado do "cuidado", o código do seu aplicativo parecerá REALMENTE diferente. Na verdade, você deve assumir que suas ferramentas AppSec de código (como seu "scanner de código") não funcionam. Todos os pontos de entrada e saída são diferentes, então seu fluxo lógico é diferente. Você precisa de ferramentas totalmente novas do AppSec para garantir que seja capaz de identificar as 10 principais vulnerabilidades do tipo OWASP (que ainda existem). Na verdade, OWASP tem toda uma que vale a pena conferir. Portanto, você ainda tem duas grandes preocupações com as quais suas ferramentas AppSec precisam ajudar: vulnerabilidades no código-fonte aberto que você traz e vulnerabilidades no código personalizado que você escreve. No entanto, há também um novo item com o qual se preocupar, que são suas permissões de gerenciamento de identidade e acesso (IAM) em cada função. É uma parte crítica de manter seu código seguro quando ele está sendo executado na nuvem pública, mas é trabalhoso de fazer manualmente. É melhor garantir que você tenha uma ferramenta que possa automatizar isso para você. Uau, isso é muito perspicaz! Portanto, apesar das compensações (prós e contras de ambos), no geral parece que a automação é um componente-chave para preencher as lacunas? Esse OWASP Top 10 parece muito interessante, com certeza vou me aprofundar mais nisso - obrigado por compartilhar! Olá Steve! Se uma organização considera mudar para ambientes sem servidor/nativos de nuvem, quais são as ameaças/perigos mais imediatos? O que as equipes de segurança devem ter em mente para melhorar a proteção?

Ei, Victor de Ávila, ótima pergunta! Embora a tecnologia sem servidor elimine muitas das responsabilidades de segurança das tecnologias subjacentes, os desenvolvedores ainda estão empenhados em proteger as funções sem servidor. Se o código for escrito de maneira insegura, o aplicativo ainda pode estar vulnerável a ataques tradicionais no nível do aplicativo, como Cross-Site Scripting (XSS), Command/SQL Injection, Denial of Service (DoS), autenticação e autorização quebradas, configurações incorretas de segurança , e muitos mais.

As equipes de segurança não devem apenas lidar com vulnerabilidades e exposições comuns (CVEs) ou riscos associados a bibliotecas de código aberto, mas os ambientes sem servidor também apresentam ameaças geradas por controle de acesso quebrado, principalmente quando os desenvolvedores precisam adicionar permissões para dar suporte à funcionalidade necessária. Nessa situação, o desenvolvedor geralmente é instruído pela equipe de segurança a selecionar em uma lista de permissões predefinidas que fornece acesso mais privilegiado do que o necessário. Um bom processo de automação pode ser uma grande oportunidade para um aplicativo de privilégio mínimo – algo que antes era impossível naquele nível. Porém, automatizar esse processo em escala, de forma precisa e rápida não é fácil.

Em um ambiente sem servidor, a superfície de ataque também aumenta, pois os ataques de desserialização são mais comuns e a auditoria e o monitoramento são mais difíceis do que em aplicativos tradicionais. Como resultado, as organizações precisam seguir os princípios de privilégio mínimo e garantir controles de acesso fortes para reduzir a superfície de ataque e garantir que apenas indivíduos autorizados possam ter acesso.

Da mesma forma, as equipes de DevSecOps também devem estar atentas à “expansão” nas funções sem servidor. As funções podem ter várias versões, em diferentes regiões e em várias contas, tornando difícil para as equipes de gerenciamento e segurança entender o tamanho geral do inventário sem servidor no nível da organização. Para resolver isso, eles precisarão de fortes controles de gerenciamento de ativos relevantes para infraestrutura em nuvem e sem servidor.

Finalmente, as equipes devem considerar suas permissões de biblioteca. Embora não seja diferente da segurança de aplicativo regular, as funções tendem a ter muitas dependências. Além disso, em alguns casos, mesmo que o código pareça limpo, a infraestrutura (como IaC) pode introduzir mais bibliotecas no momento da implantação, levando a vulnerabilidades de terceiros perdidas. As equipes de DevSecOps devem habilitar processos de segurança fortes com um olhar crítico para essas considerações específicas sem servidor. Olá Steve Wilson! Eu adoraria saber sobre seu tempo trabalhando na Oracle. O que você fez lá?

Olá, Jack Boreham, obrigado por perguntar! Trabalhei na Oracle por cerca de 3,5 anos, de 2010 a 2013. Durante esse período, fui "VP of Core Engineering" da equipe Enterprise Manager. Esse era o conjunto de ferramentas de gerenciamento da Oracle para todo o portfólio (do hardware ao hipervisor, ao banco de dados, middleware e aplicativos). É um trabalho onde aprendi muito sobre como trabalhar em escala (minha equipe era de cerca de 500 pessoas divididas entre América do Norte, Europa (França e República Tcheca) e Índia. A Oracle tinha uma cultura corporativa estranha, mas uma cultura de engenharia muito disciplinada (tendo comecei com o banco de dados Oracle). Aprendi muito sobre testes e qualidade de condução lá.

Mas, só para explicar, entrei para a Oracle quando eles adquiriram a Sun Microsystems. Na verdade, entrei na Sun em meados dos anos 90 como programador trabalhando no Java Developer Kit, onde pude trabalhar com todos os tipos de pessoas inteligentes como James Gosling (e muitos outros que se tornaram programadores famosos e construíram coisas incríveis). Comecei a trabalhar no Java GUI Toolkit e depois me tornei o primeiro Engenheiro de Desempenho em tempo integral para Java. Na verdade, escrevi um sobre isso. Vou fornecer um link apenas por diversão, mas está super desatualizado e não sugiro que ninguém o leia agora! 😉 Mudei para a gerência e liderei a equipe do NetBeans IDE (meu trabalho favorito, aliás) e depois as equipes de gerenciamento de sistemas e virtualização da Sun. Entre em contato se tiver mais perguntas sobre qualquer parte disso. Muitas histórias divertidas sobre Sun/Oracle.

Steve Wilson, essa é uma ótima jornada!
Que desafios você enfrentou em seu papel em Contrast? E o que você quer dizer com soluções de segurança de autoatendimento? Você tem um conjunto estabelecido de soluções de segurança e qualquer empresa pode simplesmente escolher o que melhor atende às suas necessidades? É possível que as empresas peçam soluções personalizadas à Contrast?

Mónica Freitas, obrigada por perguntar sobre Contraste! A Contrast é uma empresa especializada em ferramentas para ajudar os desenvolvedores a criar aplicativos seguros. Muitas pessoas pensam em coisas como ferramentas de segurança de rede, identificação ou endpoint quando consideram a segurança (e isso é importante), mas o que todos nós estamos tentando proteger dos hackers? É realmente sobre nossos aplicativos e os dados que eles estão armazenando para nós. É por isso que a segurança do aplicativo é tão importante e essas são as ferramentas que o Contrast constrói. Temos o que chamamos de Plataforma de Código Seguro. Inclui muitas tecnologias para ajudar desenvolvedores e equipes de segurança. Isso inclui varredura de código-fonte (SAST), instrumentação que pode testar seu aplicativo de "dentro para fora") IAST, proteção de tempo de execução (RASP) que pode realmente neutralizar invasores que tentam explorar vulnerabilidades de dia zero. Exemplos recentes são coisas como Log4J e Spring4Shell. E, finalmente, apresentamos recentemente as primeiras ferramentas de segurança do mundo para código Serverless nativo da nuvem. Ficaremos felizes em conversar com as pessoas sobre as melhores opções para criar um programa DevSecOps que lhes permita manter a velocidade de desenvolvimento, mas também garantir que o código seja seguro. Você pode entrar em contato para obter mais detalhes . Mónica Freitas, sobre o tema da segurança "self-service"... As soluções de segurança self-service referem-se à capacidade dos programadores de tirar partido das ferramentas Contrasts por conta própria e utilizá-las da forma que melhor entenderem. Isso significa que os desenvolvedores e as equipes de DevOps podem obter apenas as ferramentas de que precisam para realizar o trabalho e podem encontrar e corrigir vulnerabilidades com treinamento de segurança mínimo (ou supervisão constante de uma equipe de engenharia de segurança dedicada). Quanto a pedir à Contrast soluções personalizadas, com certeza. Nossa equipe é capaz de orientar as equipes sobre o que funcionará melhor com base em seus objetivos, bem como nas necessidades de longo e curto prazo. Steve Wilson, quais são os problemas de segurança mais comuns que você já viu e quais medidas as empresas podem tomar para resolvê-los? Mónica Freitas, obrigado pela pergunta sobre os problemas de segurança mais comuns. Vou evitar coisas como phishing e senhas ruins (já que isso é um terreno óbvio e bem conhecido). Em vez disso, vou me concentrar nos problemas de criação de aplicativos seguros. Há duas coisas principais que você precisa observar: proteger o código que você escreveu e proteger o código que você usa e que outra pessoa escreveu (geralmente de código aberto). Com o código que você escreve, há um grande número de tipos de vulnerabilidade classificados. Um dos mais comuns (e mais graves) é chamado de ataque de "injeção". Isso significa que uma entidade externa (um hacker!) é capaz de colocar dados em alguma parte do seu sistema de uma forma que você não previu ou pretendeu. Podem ser coisas como um "Ataque de injeção de SQL", em que um hacker é capaz de colocar um pedaço de linguagem de consulta de banco de dados em seu banco de dados e executá-lo remotamente. Isso é muito comum e tem sido um dos principais problemas por 20 anos. Outro que muitas vezes era considerado menos sério é a "Injeção de arquivo de log", em que um hacker é capaz de inserir dados corrompidos diretamente em um arquivo de log do seu aplicativo. Parece que não é tão ruim, mas isso foi o cerne do recente incidente de segurança Log4J que impactou tantas empresas em dezembro/janeiro. Quanto ao código-fonte aberto, sabemos que a maior parte do código em aplicativos de negócios modernos nem é escrita pelos desenvolvedores de uma empresa. É de código aberto. Está aberto a todos os tipos de ataques e, embora o código aberto forneça uma base sólida para o código seguro por ter muitos olhos no código, muitos desses olhos agora são hackers (de estudantes a hackers de estado-nação). Algumas dessas bibliotecas (como Struts, Log4J, Spring) são tão populares que estão incorporadas a milhões de aplicativos em todo o mundo. Alguns anos atrás, a agência de classificação de crédito chamada Equifax estava usando uma versão vulnerável do Struts e perdeu os dados financeiros pessoais de centenas de milhões de americanos. Como resultado, eles foram multados em mais de $ 400.000.000. Isso é sério. A melhor maneira de lidar com esses dois problemas é modernizar suas práticas de desenvolvimento para incluir ferramentas automatizadas que ajudam a detectar e corrigir esses tipos de problemas. A plataforma de código seguro da Contrast funciona com Java, JavaScript .NET, Go, Ruby, Python, Scala e Kotlin, portanto, se você estiver usando qualquer uma dessas tecnologias populares, ficaremos felizes em ajudá-lo a modernizar suas ferramentas e criar um programa para automatizar todas disto. Olá Steve Wilson! Estou curioso, o que são SBOMs? Eles podem afetar os sistemas de segurança? Sara Pinto, obrigada por perguntar sobre a SBOM. Uma área tão interessante e atual agora! Isso é realmente uma parte do tópico maior chamado Segurança da Cadeia de Suprimentos de Software. Conforme observado em algumas das outras perguntas neste tópico, grande parte do código em aplicativos modernos não é escrito pelos próprios desenvolvedores da empresa. É de terceiros (geralmente de código aberto). Há pouco tempo, um fornecedor de software chamado Solar Winds foi hackeado. Isso foi ruim para os ventos solares, mas o pior foi que o código que a Solar Winds construiu foi incorporado em ambientes de nuvem e data center de muitas outras empresas e até governos. Sabendo disso, os hackers que atacaram a SolarWinds não apenas roubaram da SolarWinds, como também aproveitaram a oportunidade para colocar backdoors no software da SolarWind que seriam incorporados por muitas outras empresas. A exploração foi massiva e levou à ideia de que você deve acompanhar seu próprio código, mas também o código que está obtendo de outro lugar. Todo o processo deve ser seguro de ponta a ponta e isso é chamado de Software Supply Chain Security. SBOMs significa a lista de materiais do software. Um SBOM é uma lista de todos os componentes de código aberto e de terceiros presentes em uma base de código, além de todas as licenças que regem esses componentes. Pense nisso como os rótulos nutricionais na lateral de uma caixa de alimentos. Ele ajuda o consumidor a saber o que há no alimento para que ele possa usá-lo para garantir que o alimento seja seguro e saudável para ele. Os SBOMs podem criar mais transparência no mercado de software e também permitir que os desenvolvedores ajam rapidamente se uma vulnerabilidade for identificada. A recente afirmou que os SBOMs deveriam ser exigidos e a NTIA lançou um " " para itens obrigatórios do SBOM, e muitos desses pontos foram enfatizados ainda mais na e que o acompanha . Além disso, o Gartner prevê que, até 2025, 60% das organizações que constroem ou adquirem software de infraestrutura crítica exigirão e padronizarão SBOMs em suas práticas de engenharia de software. Embora esses sejam ótimos primeiros passos para proteger aplicativos modernos, incluindo sem servidor, os desenvolvedores e as equipes de segurança ainda estão empenhados em manter seus aplicativos seguros, e essa responsabilidade recai sobre as equipes de DevSecOps. Steve Wilson, à medida que o Web3 se desenvolve, você considera a possibilidade de criar opções de segurança para o web3? Mónica Freitas, obrigado pela pergunta abound Web3 security. Este é um tópico FASCINANTE e bastante amplo. Vou tentar adicionar minha perspectiva. Primeiro, temos que definir Web3. Na cultura popular, a ideia da Web3 é dominada pela troca de peças estranhas de arte digital. Há discussões constantes sobre esquemas Ponzi e fraudes. Mas acho que os conceitos da Web3 são fascinantes. Quando você tira tudo, o Web3 é um conjunto ousado de tentativas (e tenho certeza de que muitas falharão) para reconstruir grande parte da Internet do zero. Por que precisamos fazer isso? Bem, é realmente sobre segurança e confiança! A internet e a rede mundial de computadores foram construídas por acadêmicos para acadêmicos. Eles foram feitos para abrir informações, avançar a ciência e a tecnologia e promover a troca de ideias. Nesse sentido, a internet/web é o empreendimento de maior sucesso na história da humanidade.

No entanto, devido à sua natureza, falta um conceito-chave - confiança! Como sei quem você é? Como sei o que você possui? Como sei a que você tem direito? Nada disso foi construído na internet no início. Tudo o que está em camadas em cima disso é frágil e controlado centralmente. Como sei o que você possui? Peço ao seu banco/empresa de cartão de crédito. Como sei quem você é? Uau, esse é um problema quase totalmente sem solução na internet até hoje!

Web3 tende a começar com os conceitos pioneiros de Bitcoin/Crypto-currency - com Blockchain em seu núcleo. Cerca de quatro anos atrás, descobri que minha filha adolescente e seus amigos estavam usando serviços VPN gratuitos para passar pelo firewall do ensino médio para que pudessem assistir à Netflix na escola. Em vez de ficar bravo, achei uma ótima maneira de iniciar uma conversa com ela sobre segurança e criptografia (NERD DAD ALERT!). De alguma forma, acabamos embarcando em uma aventura fabulosa minerando Ethereum e aprendendo sobre Blockchain. Você pode ler sobre algumas de nossas aventuras .

Isso me levou pessoalmente a realmente mergulhar em como o Blockchain funcionava. De certa forma, é uma maravilha da ciência da computação e, de certa forma, é um pesadelo da engenharia, mas foi pioneiro em um novo conjunto de conceitos sobre como distribuir confiança sem uma autoridade central. Este é o núcleo do web3! Como sei quem você é e o que você possui (em um determinado contexto) sem que uma instituição terceirizada no meio me diga? Se você estiver interessado em ler meus pensamentos sobre o que há de bom e ruim no blockchain, você pode conferir este . Tem alguns anos, mas os conceitos centrais aqui estão se movendo devagar o suficiente para que tudo seja amplamente relevante para a discussão. Então, agora vamos ao que interessa! O que eu diria a alguém que quer mergulhar na segurança da web3? Primeiro, existem instâncias de alto perfil de falhas de segurança em blockchains menores. A confiança na Blockchain geralmente é baseada na votação por consenso e, se você não tiver massa crítica, alguém pode possuir mais de 50% dos votos e você terá problemas. No entanto, não acho que esse seja o tópico mais importante para os desenvolvedores que analisam a Web3 hoje. Quando vejo os grandes incidentes de segurança em torno do Web3/NFT/Crypto nos últimos anos, eles não estão relacionados ao blockchain principal. Eles estão nas partes Web2 do código/infraestrutura de uma empresa que ainda mantém o mundo unido. O jogo Web3, no jogo de muito longo prazo (pense em termos de décadas), é substituir os fundamentos da Internet por coisas que incluam a confiança como um componente central. Isso pode acontecer, e é louvável, mas está muito longe. Hoje, temos coisas como IPv4/6, SSL, HTML, JavaScript, REST, AppServers, bibliotecas de código aberto e bancos de dados SQL que mantêm o mundo unido (com ilhas de tecnologias blockchain/web3). Se você estiver executando uma troca NFT (ou algo semelhante), eu gastaria tanto (ou mais) do meu tempo preocupado com a parte Web2 do meu mundo que é a cola entre mim e meus clientes/parceiros. É suscetível a todos os mesmos conceitos de segurança de aplicativos sobre os quais falamos antes aqui. Você precisa de um GRANDE programa e plataforma DevSecOps. E a maior parte deve ser semelhante a um processador de cartão de crédito ou a um grande banco. O contraste pode ajudar aqui. Se você puder endurecer sua "cola" Web2 ao mesmo nível de um grande banco, poderá gastar seu tempo se preocupando em como se diferenciar no mundo Web3. São tempos emocionantes. Mal posso esperar para ver como isso se desenvolve. Deixe-me saber se você quiser falar mais sobre este tema. Eu adoraria conversar! Steve Wilson, sou novo em todos esses padrões de segurança de software. Você poderia elaborá-los? O que devo saber sobre isso? Sara Pinto, obrigada pela pergunta sobre Padrões de Segurança de Software. Uau! Você acabou de tocar em um tópico realmente grande e importante. Existem basicamente dois tipos de normas: Contratuais/comerciais e Estatutárias. Padrões comerciais são coisas que irão ajudá-lo a fazer negócios. Aderir a um desses padrões pode ser escrito em um contrato. Por exemplo, seu cliente pode exigir que você siga um padrão chamado SOC2 e seja regularmente auditado para demonstrar isso. Por outro lado, para vender Serviços de Computação em Nuvem para o governo dos EUA, você deve aderir a um conjunto de padrões chamado FedRAMP (que é "por lei", portanto é considerado um requisito estatutário). Ambos os exemplos são interessantes e importantes se você estiver administrando uma empresa de software/SaaS. No entanto, para desenvolvedores individuais, eles são realmente abstratos. Por exemplo, esses padrões incluem muitos itens além de apenas "software". Um bom exemplo seria: você tem verificações de antecedentes suficientes e treinamento básico de segurança para todos os seus funcionários?

Para desenvolvedores de software, existem padrões mais refinados que abordam muito mais os detalhes com os quais você pode se preocupar. Aqui está uma lista parcial de coisas divertidas para começar a explorar em sua jornada! Observe que alguns requisitos são técnicos e alguns requisitos são os processos que você usa para construir o software.

Ordem Executiva de Segurança Cibernética 14028

PCI SSF (substituído PA-DSS)

OWASP

NIST

CISA

OMB

Privacidade (a segurança é uma pré-condição para a privacidade

Outro

Isso tem sido super divertido para todos. Obrigado por se juntar! Estarei assistindo este canal pelo resto do dia, mas se este for o fim deste tópico, deixarei para vocês uma coisinha que tenho trabalhado. Espero que goste! Obrigado por se juntar a nós, Steve Wilson, e por suas respostas atenciosas. Adoramos ter você aqui!