![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>A solu\u00e7\u00e3o ideal seria transferir apenas as corre\u00e7\u00f5es e vulnerabilidades mais importantes, mas a principal dificuldade est\u00e1 em identificar esses erros em meio ao fluxo geral. O maior n\u00famero de problemas pontuais \u00e9 resultado do uso da linguagem C, que exige um grande cuidado ao lidar com mem\u00f3ria e ponteiros. A situa\u00e7\u00e3o se agrava pelo fato de que muitas poss\u00edveis corre\u00e7\u00f5es de vulnerabilidades n\u00e3o s\u00e3o acompanhadas de identificadores CVE ou recebem um identificador semelhante algum tempo ap\u00f3s a publica\u00e7\u00e3o da corre\u00e7\u00e3o. Nessas condi\u00e7\u00f5es, \u00e9 muito dif\u00edcil para os fabricantes distinguir as corre\u00e7\u00f5es secund\u00e1rias dos problemas importantes que impactam a seguran\u00e7a. Stat\u00edsticas mostram que mais de 40% das vulnerabilidades s\u00e3o corrigidas antes de receber um CVE, e o atraso m\u00e9dio entre a libera\u00e7\u00e3o da corre\u00e7\u00e3o e a atribui\u00e7\u00e3o do CVE \u00e9 de tr\u00eas meses (ou seja, inicialmente a corre\u00e7\u00e3o \u00e9 percebida como um erro comum, mas apenas ap\u00f3s alguns meses fica claro que se tratava da corre\u00e7\u00e3o de uma vulnerabilidade).<\/p>\nComo resultado, sem um ramo separado para corre\u00e7\u00f5es de vulnerabilidades e sem receber informa\u00e7\u00f5es sobre a rela\u00e7\u00e3o com a seguran\u00e7a de determinado problema, os fabricantes de produtos baseados no kernel Linux s\u00e3o for\u00e7ados a transferir continuamente todas as corre\u00e7\u00f5es das \u00faltimas vers\u00f5es est\u00e1veis. No entanto, esse trabalho exige um grande esfor\u00e7o e enfrenta resist\u00eancia nas empresas devido ao receio de que ocorram mudan\u00e7as regressivas que possam comprometer o funcionamento normal do produto.<\/p>\n
Vale lembrar que, de acordo com Linus Torvalds, todos os bugs s\u00e3o importantes e as vulnerabilidades n\u00e3o devem ser separadas de outros tipos de bugs e destacadas como uma categoria de maior prioridade. Essa opini\u00e3o se explica pelo fato de que, para um desenvolvedor comum, que n\u00e3o se especializa em seguran\u00e7a, a rela\u00e7\u00e3o entre a corre\u00e7\u00e3o e a potencial vulnerabilidade n\u00e3o \u00e9 evidente (para muitas corre\u00e7\u00f5es, apenas a realiza\u00e7\u00e3o de uma auditoria separada permite entender que elas est\u00e3o relacionadas \u00e0 seguran\u00e7a). Na vis\u00e3o de Linus, a responsabilidade de identificar as potenciais vulnerabilidades no fluxo geral de corre\u00e7\u00f5es deve ser de especialistas em seguran\u00e7a das equipes respons\u00e1veis pelo suporte aos pacotes do kernel nas distribui\u00e7\u00f5es Linux.<\/p>\n
Kees Cook acredita que a \u00fanica solu\u00e7\u00e3o para manter a seguran\u00e7a do n\u00facleo com custos razo\u00e1veis de longo prazo \u00e9 transferir engenheiros das empresas que portam corre\u00e7\u00f5es para vers\u00f5es locais do n\u00facleo, para um trabalho coordenado e conjunto na manuten\u00e7\u00e3o de corre\u00e7\u00f5es e vulnerabilidades no n\u00facleo principal (upstream). No estado atual, muitos fabricantes utilizam vers\u00f5es de n\u00facleo n\u00e3o t\u00e3o atualizadas em seus produtos e backportam corre\u00e7\u00f5es por conta pr\u00f3pria, ou seja, os engenheiros de diferentes empresas acabam duplicando o trabalho uns dos outros ao resolver o mesmo problema.<\/p>\n
Por exemplo, se 10 empresas, cada uma com um engenheiro realizando o backport de corre\u00e7\u00f5es semelhantes, redirecionassem esses engenheiros para corrigir falhas no upstream, em vez de realizar o porting de uma \u00fanica corre\u00e7\u00e3o, poderiam corrigir 10 falhas diferentes para o benef\u00edcio comum ou se envolver em revisar as altera\u00e7\u00f5es propostas e prevenir que c\u00f3digo com erros fosse inclu\u00eddo no n\u00facleo. Os recursos tamb\u00e9m poderiam ser direcionados para a cria\u00e7\u00e3o de novas ferramentas de teste e an\u00e1lise de c\u00f3digo que permitem identificar automaticamente em uma fase inicial classes de erros recorrentes.<\/p>\n
Kees Cook tamb\u00e9m sugere utilizar mais ativamente testes automatizados e fuzzing diretamente no processo de desenvolvimento do n\u00facleo, aplicar sistemas de integra\u00e7\u00e3o cont\u00ednua e abandonar a gest\u00e3o arcaica do desenvolvimento via e-mail. Atualmente, a efic\u00e1cia do teste \u00e9 prejudicada pelo fato de que os principais processos de teste est\u00e3o separados do desenvolvimento e ocorrem apenas ap\u00f3s a forma\u00e7\u00e3o das vers\u00f5es. Kees tamb\u00e9m recomendou, para reduzir o n\u00famero de erros, utilizar linguagens que proporcionam mais alto n\u00edvel de seguran\u00e7a<\/a>, como Rust.<\/p>\n