Vamos abordar neste artigo alguns pontos que podem ajudar a entender por que o planejamento de segurança nas sprints também deveria ser considerado importante e deveria fazer parte da dinâmica de um Product Owner.
Você também pode ouvir esse conteúdo:
Quando falamos de desenvolvimento de software, sempre ouvimos falar que um dos grandes problemas de segurança é a visão de que “segurança se se pensa depois, primeiro vamos entregar a aplicação”. Essa visão tem uma série de problemas, mas hoje vamos falar sobre um outro ponto que poucos estão atentos: Software Supply Chain.
Pensar que segurança é um ponto que pode ser trabalhado posteriormente não apenas aumenta a sua lista de coisas a resolver – conhecido como backlog – como também termina por minar a confiança do seu cliente com seu trabalho.
Alguns dados
Uma pesquisa realizada pela CloudBees aponta que 95% dos executivos de C-Level estão mais preocupados em proteger as suas cadeias de suprimento para a produção de suas aplicações. No entanto, mesmo com essa visão mudando, ainda temos alguns caminhos a percorrer.
Um bom exemplo foi quando os eventos envolvendo a Log4J levaram várias equipes de desenvolvimento a realizar buscas por componentes afetados. Claramente o uso de ferramentas usando conceitos de SBOM teriam resolvido este ponto de forma muito rápida e prática.
Ainda, em outra pesquisa, desta vez realizada pela Venati, temos 61% de executivos que entendem que preocupação com Software Supply Chain deve ser de responsabilidade da equipe de TI, e temos 31% entendendo que essa responsabilidade deve ser dos times de desenvolvimento. Além disso, 94% destes mesmos executivos entendem que o vendor deveria ser punido por estas fragilidades em seus sistemas.
Depois de todos estes pontos, podemos entender que estamos diante de uma situação bem clara: Segurança de software deve ser incorporada no processo de desenvolvimento o mais cedo possível. O planejamento dos aspectos de segurança de um software podem permitir às empresas a construírem suas soluções de forma mais segura, prática e efetiva.
O planejamento de Segurança nas sprints
Entendendo que a definição de segurança de um software deve caminhar desde o início da aplicação, passando por sua definição de requisitos e seu desenho como solução, ainda assim temos um ponto bastante forte a considerar.
O modelo ágil, por definição, pode ser contrário ao processo de mitigação de riscos ou mesmo para a produção de cobertura de segurança. Modelos ágeis usam o Scrum como framework. As atividades e tarefas são quebradas em atividades que podem ser realizadas dentro de um tempo fixo, chamadas de sprints.
Todas as atividades a serem desenvolvidas vêm de uma lista chamada backlog, que por definição é uma lista composta de requisitos funcionais e também não-funcionais. A partir desta lista, as atividades são retiradas e trabalhadas, e quando a sprint se encerra, os cards são colocados como fechados. Isso ocorre para mostrar progresso no processo de construção da aplicação. Neste cenário, o elemento mais importante é o tempo!
Quando se coloca segurança dentro do processo, e se criam cards para representar estas necessidades, é possível que o backlog seja impactado, tendo muitas outras atividades, e que dentro do tempo determinado, fechar aquelas atividades ficaria inviável.
Este é o ponto: chegamos onde devemos começar a falar sobre a importância de termos Product Owners realmente interessados, focados e proativos quando o tema é segurança de aplicações.
Afinal, onde atuaria um Product Owner em um SDLC?
Primeiro vamos relembrar qual é a função de um Product Owner.
Dentro do processo de desenvolvimento, a figura do Product Owner ou simplesmente PO tem como função definir o backlog, e ainda, converter as histórias de usuários ou mesmo os caso de uso do produto em requisitos funcionais e em requisitos não-funcionais, basicamente é isso.
Quando, por alguma razão o Product Owner traz algum ponto de segurança para a sprint, esse geralmente recebe menos importância que as definições e execuções de requisitos funcionais ou não-funcionais. Ainda, temos um aspecto cultural muito forte: é normal equipes de desenvolvimento terem o entendimento que aspectos de segurança devem ser validados e vistos por times específicos, e que outros podem realizar atividades de code review, por exemplo.
Mas eles esquecem de uma coisa muito importante, e para isso vou tentar responder primeiro fazendo uma pergunta:
Qual seria então o foco principal de modelos ágeis de desenvolvimento? Não seria, dentre vários, outro o ganho de tempo para o desenvolvimento?
Pois bem, se pensarmos que outros times deveriam se preocupar com segurança e depois realizar os testes, o que aconteceria com as vulnerabilidades e/ou erros de codificação encontrados? Estes não voltariam para o time de desenvolvimento corrigir? E o que aconteceu com o tempo que foi ganho no primeiro momento?
Eu respondo: Foi perdido com o retrabalho!
Otimização do tempo
Então, respondendo à pergunta de nosso tópico, o PO deveria estar preocupado em entender as necessidades de criação de histórias e casos de uso, mas também deveria estar preocupado em incluir nestes pontos os requisitos de segurança, já pensando em realmente aproveitar da melhor forma possível o tempo de seu time.
Então, novamente tudo se resume a um uso efetivo e eficaz do tempo!
E você pode estar se perguntando agora: Ok, mas quais seriam os reais benefícios de meu Product Owner planejando segurança nas sprints?
Bom, vou tentar listar alguns aqui.
Não sei quanto a vocês, mas para mim fica bem claro que um dos ganhos principais seriam de tempo. Teríamos muito menos retrabalho. Precisaríamos trabalhar menos em correção de pontos que claramente já poderiam ter sido desenvolvidos de forma correta.
Outro ponto que vejo como bem claro é quanto a posturas de compliance que já seriam atendidas nos primeiros estágios de um desenvolvimento, isso poderia evitar uma série de problemas, se todos soubessem o que realmente devem construir.
Vejo outro: esse tipo de postura demonstraria para seu cliente uma visão e preocupação em ter um produto seguro, que tem como foco a manutenção da sua privacidade, acho que isso já é por si só uma coisa muito interessante a ser colocada aqui, mas vamos em frente.
Por último, mas não menos importante: você, enquanto desenvolvedor, já construiria um software com base sólidas de segurança.
Mas, e como eu enquanto Product Owner posso fazer essa priorização?
Bom, vejo duas formas que isso pode ser apresentado dentro do processo de desenvolvimento.
O primeiro é imaginar que você terá um momento exclusivo para o planejamento de segurança da sprint. Neste momento, você deve identificar tudo que será realizado dentro da sprint, user stories ou mesmo product use case, e já construa a visão de segurança necessária para a sprint, ou seja, teremos sprints exclusivas de segurança onde teremos code review, revisão de design ou de arquitetura e até mesmo para a construção de requisitos de segurança.
O segundo modelo que imagino é quando os requisitos de segurança são incluídos nas atividades das sprints regulares. Aqui acontece o processo normal de planejamento das atividades, com as definições de requisitos que serão entregues. Mas, neste caso, também teremos atividades focadas em segurança da aplicação.
Bom, independentemente se você vai usar uma das duas visões que coloquei aqui uma coisa não pode ser ignorada, os Product Owners não podem mais ignorar a segurança das aplicações, elas precisam fazer parte do seu dia a dia.
E você o que pensa sobre isso?
