{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Medo e \u00f3dio no DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

T\u00ednhamos 2 analisadores de c\u00f3digo, 4 ferramentas para testes din\u00e2micos, nossas cria\u00e7\u00f5es e 250 scripts. N\u00e3o que tudo isso fosse necess\u00e1rio no processo atual, mas, uma vez que come\u00e7amos a implementar o DevSecOps, \u00e9 preciso ir at\u00e9 o fim.<\/p>\n

\"Medo
\n
\nFonte<\/a><\/noindex>. Criadores dos personagens: Justin Roiland e Dan Harmon.<\/i><\/p>\n

O que \u00e9 SecDevOps? E DevSecOps? Quais s\u00e3o as diferen\u00e7as? O que \u00e9 Seguran\u00e7a de Aplica\u00e7\u00e3o? Por que a abordagem cl\u00e1ssica n\u00e3o funciona mais? Todas essas perguntas t\u00eam resposta Yuri Shabalin<\/b> do\u00a0Swordfish Security. <\/b>Yuri responder\u00e1 tudo em detalhes e analisar\u00e1 os problemas da transi\u00e7\u00e3o do modelo cl\u00e1ssico de Seguran\u00e7a de Aplica\u00e7\u00e3o para o processo DevSecOps: como abordar corretamente a incorpora\u00e7\u00e3o do processo de desenvolvimento seguro no processo DevOps sem quebrar nada, como passar pelas principais etapas de teste de seguran\u00e7a, quais ferramentas podem ser aplicadas, como se diferenciam e como configur\u00e1-las corretamente para evitar armadilhas.
\n<\/a><\/noindex>
\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center>
\nSobre o palestrante:<\/b> Yuri Shabalin \u00e9 <\/b>Arquiteto Chefe de Seguran\u00e7a na Swordfish Security<\/b>. Respons\u00e1vel pela implementa\u00e7\u00e3o do SSDL, pela integra\u00e7\u00e3o geral das ferramentas de an\u00e1lise de aplica\u00e7\u00f5es em um \u00fanico ecossistema de desenvolvimento e teste. 7 anos de experi\u00eancia em seguran\u00e7a da informa\u00e7\u00e3o. Trabalhou no Alfa-Bank, Sberbank e na Positive Technologies, que desenvolve software e fornece servi\u00e7os. Palestrante em confer\u00eancias internacionais como ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Seguran\u00e7a de Aplica\u00e7\u00e3o: o que \u00e9?<\/h2>\n

\nSeguran\u00e7a de Aplica\u00e7\u00e3o<\/b>\u00a0\u00e9 uma disciplina de seguran\u00e7a que se ocupa da seguran\u00e7a das aplica\u00e7\u00f5es. Isso n\u00e3o se refere \u00e0 infraestrutura ou \u00e0 seguran\u00e7a de rede, mas sim ao que escrevemos e no que os desenvolvedores trabalham \u2014 s\u00e3o as falhas e vulnerabilidades da pr\u00f3pria aplica\u00e7\u00e3o.<\/p>\n

Dire\u00e7\u00e3o SDL ou SDLC<\/a><\/noindex>\u00a0\u2014 Ciclo de vida de desenvolvimento de seguran\u00e7a<\/b>\u00a0foi desenvolvido pela Microsoft. Na imagem \u2014 modelo can\u00f4nico de SDLC, cuja principal tarefa \u00e9 a participa\u00e7\u00e3o da seguran\u00e7a em cada etapa do desenvolvimento, desde os requisitos at\u00e9 o lan\u00e7amento e a produ\u00e7\u00e3o. A Microsoft percebeu que havia muitos bugs no produto, que estavam se tornando mais frequentes, e que era necess\u00e1rio fazer algo a respeito, ent\u00e3o prop\u00f4s essa abordagem que se tornou can\u00f4nica.<\/p>\n

\"Medo
\n
\nA Seguran\u00e7a de Aplica\u00e7\u00e3o e o SSDL n\u00e3o t\u00eam como foco a detec\u00e7\u00e3o de vulnerabilidades, como se costuma pensar, mas sim a preven\u00e7\u00e3o de seu surgimento. Com o tempo, a abordagem can\u00f4nica da Microsoft foi aprimorada e expandida, permitindo um mergulho mais profundo e detalhado.<\/p>\n

\"Medo
\n
\nO SDLC can\u00f4nico \u00e9 altamente detalhado em v\u00e1rias metodologias - OpenSAMM, BSIMM, OWASP. As metodologias diferem, mas, no geral, s\u00e3o semelhantes.<\/p>\n

Modelo de Maturidade para Construir Seguran\u00e7a<\/h3>\n

\nEu prefiro BSIMM<\/b>\u00a0\u2014 Modelo de Maturidade para Construir Seguran\u00e7a<\/a><\/noindex>. A base da metodologia \u00e9 a divis\u00e3o do processo de Seguran\u00e7a da Aplica\u00e7\u00e3o em 4 dom\u00ednios: Governan\u00e7a, Intelig\u00eancia, Pontos de Contato SSDL e Implanta\u00e7\u00e3o. Em cada dom\u00ednio, existem 12 pr\u00e1ticas, apresentadas na forma de 112 atividades.<\/p>\n

\"Medo
\n
\nCada uma das 112 atividades tem 3 n\u00edveis de maturidade<\/b>: inicial, intermedi\u00e1rio e avan\u00e7ado. As 12 pr\u00e1ticas podem ser estudadas por se\u00e7\u00f5es, selecionar os t\u00f3picos importantes para voc\u00ea, entender como implement\u00e1-los e gradualmente adicionar elementos, como an\u00e1lise est\u00e1tica e din\u00e2mica de c\u00f3digo ou revis\u00e3o de c\u00f3digo. Voc\u00ea elabora um plano e, com ele, trabalha tranquilamente dentro do escopo das atividades escolhidas.<\/p>\n

Por que DevSecOps<\/h2>\n

<\/p>\n

DevOps \u00e9 um processo amplo em que \u00e9 necess\u00e1rio se preocupar com a seguran\u00e7a.<\/p><\/blockquote>\n

\nInicialmente DevOps<\/b><\/a><\/noindex> se previa a realiza\u00e7\u00e3o de verifica\u00e7\u00f5es de seguran\u00e7a. Na pr\u00e1tica, o n\u00famero de equipes de seguran\u00e7a era muito menor do que hoje, e elas atuavam n\u00e3o como participantes do processo, mas como uma entidade de controle e supervis\u00e3o que imp\u00f5e requisitos e verifica a qualidade do produto no final do lan\u00e7amento. Esse \u00e9 o abordado cl\u00e1ssico, no qual as equipes de seguran\u00e7a estavam isoladas da equipe de desenvolvimento e n\u00e3o participavam do processo.<\/p>\n

\"Medo
\n
\nO principal problema reside no fato de que a seguran\u00e7a da informa\u00e7\u00e3o est\u00e1 separada do desenvolvimento. Normalmente, h\u00e1 um certo contorno de seguran\u00e7a da informa\u00e7\u00e3o e nele est\u00e3o 2-3 grandes e caras ferramentas. A cada seis meses, chega o c\u00f3digo-fonte ou o aplicativo que precisa ser verificado, e uma vez por ano s\u00e3o realizados testes de penetra\u00e7\u00e3o<\/a><\/noindex>. Tudo isso leva ao atraso dos prazos de lan\u00e7amento no mercado, enquanto o desenvolvedor se depara com uma quantidade enorme de vulnerabilidades geradas por ferramentas automatizadas. Tudo isso \u00e9 imposs\u00edvel de ser analisado e corrigido, porque ainda n\u00e3o se analisaram os resultados dos \u00faltimos seis meses e aqui chega uma nova leva.<\/p>\n

Durante o processo de trabalho da nossa empresa, vemos que a seguran\u00e7a em todos os setores e ind\u00fastrias reconhece que \u00e9 hora de se alinhar e girar junto com o desenvolvimento na mesma engrenagem - no\u00a0Agile<\/b><\/a><\/noindex>. A paradigma DevSecOps se encaixa perfeitamente na metodologia de desenvolvimento \u00e1gil, na implementa\u00e7\u00e3o, suporte e participa\u00e7\u00e3o em cada lan\u00e7amento e itera\u00e7\u00e3o.<\/p>\n

\"Medo
\n<\/p>\n

A transi\u00e7\u00e3o para DevSecOps<\/h2>\n

\nA palavra mais importante no Ciclo de Vida do Desenvolvimento de Seguran\u00e7a \u00e9 \"processo\"<\/b>Voc\u00ea precisa entender isso antes de pensar em comprar ferramentas.<\/p>\n

Apenas incluir ferramentas no processo DevOps n\u00e3o \u00e9 suficiente \u2014 a intera\u00e7\u00e3o e compreens\u00e3o entre os participantes do processo s\u00e3o importantes.<\/p><\/blockquote>\n

<\/p>\n

As pessoas s\u00e3o mais importantes do que as ferramentas.<\/h3>\n

\nFrequentemente, o planejamento do processo de desenvolvimento seguro come\u00e7a com a escolha e compra de uma ferramenta e termina com tentativas de integrar a ferramenta ao processo atual, que permanecem apenas tentativas. Isso leva a consequ\u00eancias infelizes, pois cada ferramenta tem suas caracter\u00edsticas e limita\u00e7\u00f5es.<\/p>\n

Um caso comum \u00e9 quando o departamento de seguran\u00e7a escolhe uma boa ferramenta cara, com amplas capacidades, e chega aos desenvolvedores \u2014 para integr\u00e1-la no processo. Mas n\u00e3o funciona \u2014 o processo est\u00e1 estruturado de tal forma que as limita\u00e7\u00f5es da ferramenta j\u00e1 comprada n\u00e3o se encaixam na atual paradigma.<\/p>\n

Primeiro, descreva qual resultado voc\u00ea deseja e como o processo deve ser. Isso ajudar\u00e1 a entender os pap\u00e9is da ferramenta e da seguran\u00e7a no processo.<\/p><\/blockquote>\n

<\/p>\n

Comece com o que j\u00e1 est\u00e1 em uso.<\/h3>\n

\nAntes de comprar ferramentas caras, veja o que voc\u00ea j\u00e1 tem. Cada empresa tem requisitos de seguran\u00e7a que s\u00e3o exigidos para o desenvolvimento, h\u00e1 auditorias, testes de penetra\u00e7\u00e3o \u2014 por que n\u00e3o transformar tudo isso em uma forma compreens\u00edvel e conveniente para todos?<\/p>\n

Geralmente, os requisitos s\u00e3o um documento extenso que fica em uma prateleira. Houve um caso em que chegamos a uma empresa para revisar os processos e pedimos para ver os requisitos de seguran\u00e7a do software. O especialista respons\u00e1vel passou um bom tempo procurando:<\/p>\n

\u2014 Agora, em algum lugar nas anota\u00e7\u00f5es estava o caminho onde esse documento est\u00e1.<\/i><\/p>\n

No final, recebemos o documento ap\u00f3s uma semana.<\/p>\n

Para requisitos, auditorias e outros, crie uma p\u00e1gina, por exemplo, no\u00a0Confluence<\/b>\u00a0\u2014 isso \u00e9 conveniente para todos.<\/p>\n

\u00c9 mais f\u00e1cil reformular o que j\u00e1 existe e usar isso como ponto de partida.<\/p><\/blockquote>\n

<\/p>\n

Use os Security Champions. <\/h3>\n

\nNormalmente, em uma empresa m\u00e9dia com 100-200 desenvolvedores, h\u00e1 um especialista em seguran\u00e7a que desempenha v\u00e1rias fun\u00e7\u00f5es e n\u00e3o consegue verificar tudo fisicamente. Mesmo que ele se esforce ao m\u00e1ximo \u2014 sozinho n\u00e3o conseguir\u00e1 revisar todo o c\u00f3digo que a equipe de desenvolvimento gera. Para tais casos, foi desenvolvido o conceito \u2014 Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions s\u00e3o pessoas dentro da equipe de desenvolvimento que est\u00e3o interessadas na seguran\u00e7a do seu produto.<\/p><\/blockquote>\n

\"Medo
\n
\nSecurity Champion \u00e9 o ponto de entrada na equipe de desenvolvimento e o evangelista de seguran\u00e7a em uma \u00fanica pessoa.<\/p>\n

Normalmente, quando um especialista em seguran\u00e7a chega \u00e0 equipe de desenvolvimento e aponta um erro no c\u00f3digo, ele recebe uma resposta surpreendida:<\/p>\n

\u2014 E voc\u00ea quem \u00e9? Eu nunca te vi antes. Est\u00e1 tudo bem para mim \u2014 meu colega mais experiente deu \u2018aplicar\u2019 na revis\u00e3o do c\u00f3digo, vamos seguir em frente!<\/i><\/p>\n

Essa \u00e9 uma situa\u00e7\u00e3o t\u00edpica, porque h\u00e1 muito mais confian\u00e7a em colegas seniores ou simplesmente em colegas de equipe com os quais o desenvolvedor interage constantemente nas revis\u00f5es de c\u00f3digo. Se, ao inv\u00e9s de um especialista em seguran\u00e7a, for um Security Champion a apontar o erro e suas consequ\u00eancias, sua palavra ter\u00e1 mais peso.<\/p>\n

Al\u00e9m disso, os desenvolvedores conhecem melhor seu c\u00f3digo do que qualquer especialista em seguran\u00e7a. Para uma pessoa que analisa pelo menos 5 projetos em uma ferramenta de an\u00e1lise est\u00e1tica, \u00e9 normalmente dif\u00edcil lembrar de todos os detalhes. Security Champions conhecem seu produto: o que interage com o qu\u00ea e a que devem prestar aten\u00e7\u00e3o primeiro \u2014 eles s\u00e3o mais eficazes.<\/p>\n

Ent\u00e3o, considere implementar Security Champions e ampliar a influ\u00eancia da equipe de seguran\u00e7a. Para o pr\u00f3prio campe\u00e3o, isso tamb\u00e9m \u00e9 vantajoso: desenvolvimento profissional em uma nova \u00e1rea, amplia\u00e7\u00e3o da vis\u00e3o t\u00e9cnica, aprimoramento de habilidades t\u00e9cnicas, gerenciais e de lideran\u00e7a, aumento do valor no mercado. \u00c9 um certo elemento de engenharia social, seus \u2018olhos\u2019 na equipe de desenvolvimento.<\/p>\n

Fases de teste<\/h2>\n

\nA Paradigma 20 por 80<\/a><\/noindex>\u00a0diz que 20% dos esfor\u00e7os d\u00e3o 80% dos resultados. Esses 20% s\u00e3o pr\u00e1ticas de an\u00e1lise de aplica\u00e7\u00f5es que podem e devem ser automatizadas. Exemplos de tais atividades s\u00e3o an\u00e1lise est\u00e1tica \u2014 SAST<\/b>, an\u00e1lise din\u00e2mica \u2014 DAST,<\/b> e\u00a0controle de Open Source<\/b>. Vou falar mais sobre as atividades, assim como sobre as ferramentas, quais peculiaridades normalmente encontramos ao implement\u00e1-las no processo e como faz\u00ea-lo corretamente.<\/p>\n

\"Medo
\n<\/p>\n

Principais problemas das ferramentas<\/h3>\n

\nDestacarei problemas relevantes para todas as ferramentas que exigem aten\u00e7\u00e3o. Vou analis\u00e1-los mais detalhadamente, para n\u00e3o me repetir depois.<\/p>\n

Longo tempo de an\u00e1lise. <\/b>Se de um commit at\u00e9 o lan\u00e7amento em produ\u00e7\u00e3o leva 30 minutos para todos os testes e a montagem, as verifica\u00e7\u00f5es de seguran\u00e7a da informa\u00e7\u00e3o levar\u00e3o um dia. Ningu\u00e9m vai atrasar o processo assim. Considere essa particularidade e tire suas conclus\u00f5es.<\/p>\n

Alto n\u00edvel de Falso Negativo ou Falso Positivo. <\/b>Todos os produtos s\u00e3o diferentes, todos usam diferentes frameworks e t\u00eam seu pr\u00f3prio estilo de codifica\u00e7\u00e3o. Em diferentes bases de c\u00f3digo e tecnologias, as ferramentas podem mostrar diferentes n\u00edveis de Falso Negativo e Falso Positivo. Portanto, veja o que exatamente em\u00a0sua<\/b> empresa e seus<\/b> aplicativos mostrar\u00e3o bons e confi\u00e1veis resultados.<\/p>\n

Sem integra\u00e7\u00f5es com ferramentas existentes<\/b>. Veja as ferramentas do ponto de vista das integra\u00e7\u00f5es, com o que voc\u00ea j\u00e1 est\u00e1 utilizando. Por exemplo, se voc\u00ea tem Jenkins ou TeamCity, verifique a integra\u00e7\u00e3o das ferramentas exatamente com esse software, e n\u00e3o com GitLab CI, que voc\u00ea n\u00e3o utiliza.<\/p>\n

Falta ou complexidade excessiva de personaliza\u00e7\u00e3o. <\/b>Se a ferramenta n\u00e3o tem API, por que ela \u00e9 necess\u00e1ria? Tudo que pode ser feito na interface deve estar dispon\u00edvel atrav\u00e9s da API. Idealmente, a ferramenta deve permitir a personaliza\u00e7\u00e3o das verifica\u00e7\u00f5es.<\/p>\n

Sem Roadmap de desenvolvimento do produto. <\/b>O desenvolvimento n\u00e3o para, estamos sempre usando novos frameworks e fun\u00e7\u00f5es, reescrevendo o c\u00f3digo antigo em novas linguagens. Queremos ter certeza de que a ferramenta que comprarmos suportar\u00e1 novos frameworks e tecnologias. Portanto, \u00e9 importante saber que o produto tem um real e adequado Roteiro<\/a><\/noindex> desenvolvimento.<\/p>\n

Particularidades do processo<\/h3>\n

\nAl\u00e9m das particularidades das ferramentas, considere tamb\u00e9m as particularidades do processo de desenvolvimento. Por exemplo, interromper o desenvolvimento \u00e9 um erro t\u00edpico. Vamos ver quais outras particularidades devem ser consideradas e em que a equipe de seguran\u00e7a deve prestar aten\u00e7\u00e3o.<\/p>\n

Para n\u00e3o atrasar os prazos de desenvolvimento e lan\u00e7amento, crie regras diferentes<\/b> e diferentes show stoppers\u00a0<\/b>\u2014 crit\u00e9rios para interromper o processo de montagem na presen\u00e7a de vulnerabilidades \u2014 para diferentes ambientes<\/b>. Por exemplo, entendemos que o branch atual vai para o ambiente de desenvolvimento ou UAT, ent\u00e3o n\u00e3o vamos parar e dizer:<\/p>\n

\u2014 Voc\u00ea tem vulnerabilidades aqui, voc\u00eas n\u00e3o podem seguir adiante!<\/i><\/p>\n

Neste est\u00e1gio, \u00e9 importante informar aos desenvolvedores que existem problemas de seguran\u00e7a que devem ser observados.<\/p>\n

A presen\u00e7a de vulnerabilidades n\u00e3o \u00e9 um impedimento para testes adicionais<\/b>: manuais, integra\u00e7\u00f5es ou manuais. Por outro lado, precisamos de alguma forma aumentar a seguran\u00e7a do produto, e para que os desenvolvedores n\u00e3o ignorem o que a seguran\u00e7a encontra. Portanto, \u00e0s vezes fazemos o seguinte: na bancada, quando \u00e9 lan\u00e7ado no ambiente de desenvolvedor, apenas notificamos a equipe de desenvolvimento:<\/p>\n

\u2014 Pessoal, voc\u00eas t\u00eam problemas, por favor, prestem aten\u00e7\u00e3o neles.<\/i><\/p>\n

Na fase de UAT, novamente mostramos os avisos sobre vulnerabilidades, e na fase de lan\u00e7amento ao p\u00fablico, dizemos:<\/p>\n

\u2014 Pessoal, avisamos v\u00e1rias vezes, voc\u00eas n\u00e3o fizeram nada \u2014 n\u00e3o vamos liberar voc\u00eas com isso.<\/i><\/p>\n

Se falarmos sobre c\u00f3digo e din\u00e2mica, \u00e9 necess\u00e1rio mostrar e avisar sobre as vulnerabilidades apenas das funcionalidades e do c\u00f3digo que foram escritos recentemente nesta feature. Se um desenvolvedor moveu um bot\u00e3o em 3 pixels e dizemos a ele que h\u00e1 uma inje\u00e7\u00e3o SQL l\u00e1 e que precisa ser corrigido urgentemente \u2014 isso est\u00e1 incorreto. Olhem apenas para o que foi escrito agora e para a mudan\u00e7a que est\u00e1 sendo introduzida no aplicativo.<\/p>\n

Suponha que temos um defeito funcional \u2014 como o aplicativo n\u00e3o deve funcionar: dinheiro n\u00e3o \u00e9 transferido, ao clicar no bot\u00e3o n\u00e3o ocorre transi\u00e7\u00e3o para a pr\u00f3xima p\u00e1gina ou o produto n\u00e3o carrega. Defeitos de seguran\u00e7a<\/b>\u00a0\u2014 s\u00e3o defeitos similares, mas n\u00e3o em termos de funcionamento do aplicativo, mas sim de seguran\u00e7a. <\/p>\n

Nem todos os problemas de qualidade de software s\u00e3o problemas de seguran\u00e7a. Mas todos os problemas de seguran\u00e7a est\u00e3o relacionados \u00e0 qualidade do software. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nComo todas as vulnerabilidades s\u00e3o defeitos, elas devem estar no mesmo lugar que todos os defeitos de desenvolvimento. Portanto, esque\u00e7am os relat\u00f3rios e os PDFs assustadores que ningu\u00e9m l\u00ea.<\/p>\n

\"Medo
\n
\nQuando eu trabalhava em uma empresa de desenvolvimento, recebi um relat\u00f3rio de ferramentas de an\u00e1lise est\u00e1tica. Eu o abri, fiquei horrorizado, preparei um caf\u00e9, folheei 350 p\u00e1ginas, fechei e fui trabalhar novamente. Relat\u00f3rios grandes s\u00e3o relat\u00f3rios mortos<\/b>. Normalmente, eles n\u00e3o v\u00e3o a lugar nenhum, os e-mails s\u00e3o deletados, esquecidos, perdidos ou a empresa diz que aceita os riscos.<\/p>\n

O que fazer? Os defeitos confirmados que encontramos s\u00e3o simplesmente transformados em uma forma amig\u00e1vel para desenvolvimento, por exemplo, armazenando no backlog no Jira. Priorizamos os defeitos e os corrigimos na ordem de prioridade, juntamente com os defeitos funcionais e de teste.<\/p>\n

An\u00e1lise Est\u00e1tica - SAST<\/h2>\n

\n\u00c9 uma an\u00e1lise de c\u00f3digo em busca de vulnerabilidades<\/b>, mas n\u00e3o \u00e9 a mesma coisa que o SonarQube. Verificamos n\u00e3o apenas por padr\u00f5es ou estilo. Na an\u00e1lise, \u00e9 aplicado um conjunto de abordagens: por meio da \u00e1rvore de vulnerabilidades, por\u00a0DataFlow<\/a><\/noindex>, atrav\u00e9s da an\u00e1lise de arquivos de configura\u00e7\u00e3o. Isso \u00e9 tudo que diz respeito diretamente ao c\u00f3digo.<\/p>\n

Vantagens da abordagem<\/b>: detec\u00e7\u00e3o de vulnerabilidades no c\u00f3digo em uma fase inicial do desenvolvimento<\/b>, quando ainda n\u00e3o h\u00e1 ambientes e ferramentas prontas, e\u00a0possibilidade de escaneamento incremental<\/b>: escanear a parte do c\u00f3digo que foi alterada e apenas a funcionalidade que estamos desenvolvendo agora, o que reduz o tempo de escaneamento.<\/p>\n

Desvantagens<\/b>\u00a0\u2014 \u00e9 a falta de suporte para as linguagens necess\u00e1rias.<\/p>\n

Integra\u00e7\u00f5es necess\u00e1rias, <\/b>que devem estar nas ferramentas, na minha opini\u00e3o subjetiva:<\/p>\n