Os requisitos de seguranca de software sao o conjunto de necessidades de seguranca que o software deve atender, sendo tais necessidades influenciadas fortemente pela politica de seguranca da organizacao, e compreendendo aspectos funcionais e nao-funcionais. Os aspectos funcionais descrevem comportamentos que viabilizam a criacao ou a manutencao da seguranca e, geralmente, podem ser testados diretamente. Na maioria dos casos, remetem a mecanismos de seguranca como, por exemplo, controle de acesso baseado em papeis de usuarios (administradores, usuarios comuns, entre outros.), autenticacao com o uso de credenciais (usuario e senha, certificados digitais, entre outros.), dentre outros. Os aspectos nao funcionais descrevem procedimentos necessarios para que o software permaneca executando suas funcoes adequadamente mesmo sob uso indevido. Sao exemplos de requisitos nao funcionais: validacao de dados de entrada e a registro eventos em log de auditoria com informacoes suficientes para analise forense.A elicitacao de requisitos de seguranca de software consiste na definicao das necessidades de protecao exigidas pelo software. Tal atividade exige uma colaboracao intensa entre os interessados no software, especialmente daqueles com visao negocial, que podem ter consciencia das consequencias no negocio decorrentes de incidentes de seguranca, cujo vetor de ataque se localize no software.Algumas das tecnicas mais usadas no levantamento de requisitos de seguranca incluem:Brainstorming.Pesquisas de opiniao (questionarios e entrevistas).Decomposicao da politica.Classificacao de dados.Matriz de objeto-sujeito.Modelagem de caso de uso e abuso.Independente da tecnica a ser usada, a elicitacao de requisitos exige que pelo menos um dos participantes na atividade tenha densidade em seguranca de software, para que os fluxos regulares que o software provera ou ja provem sejam criticados, evidenciando maneiras de subverte-los. A definicao dos cenarios negativos, cuja realizacao e indesejada, resultara no requisito de seguranca. Segue, a titulo de ilustracao, alguns exemplos de requisitos de seguranca, retirados do livro Official (ISC)2 guide to the CSSLP by Mano PaulConfidencialidadeSenha e outros campos de entrada de dados sensiveis necessitam ser mascarados.Senhas nao devem ser armazenadas as claras nos sistemas backend, e quando armazenadas devem passar por processo de hash com uma funcao pelo menos equivalente a SHA-256.Transport Layer Security (TLS) como Secure Socket Layer (SSL) deve ser colocado em pratica para proteger contra ameacas internas de Man in the Middle (MITM) para todas as informacoes de cartao de credito que seja transmitida.O uso de protocolos reconhecidamente inseguros como, por exemplo, File Transfer Protocol (FTP) para transmitir credenciais de contas em texto claro a terceiros fora de sua organizacao deve ser proibido.Arquivos de log nao devem armazenar qualquer informacao sensivel como definido pelo negocio, de modo que seja compreensivel por seres humanos.IntegridadeTodos os formularios de entrada e query strings necessitam ser validadas frente a um conjunto de entradas aceitaveis, antes do software aceita-los para processamento.O software a ser publicado deve ser disponibilizado juntamente com o checksum e a funcao hash usada pra computar o checksum, de modo que o interessado possa validar sua precisao e completude.Todos os personagens nao humanos como um sistema ou processos batch devem ser identificados, monitorados e impedidos de alteracao de dados, a medida que ele passa no sistema que eles rodam, a nao ser que explicitamente autorizado