Por Ricardo Caetano, Diretor de Projetos da Opensoft
Dados do estudo “State of Open” estimam que, na atualidade, 80% a 90% das organizações dependa de componentes ou frameworks open source. Estes componentes podem ser obtidos diretamente de sites como o GitHub, SourceForge, Bitbucket, ou de repositórios de bibliotecas, como o Maven Central ou o npm.js, sendo múltiplas as vantagens que fornecem às organizações.
A transparência do código é uma das mais óbvias, uma vez que é possível aceder, avaliá-lo sobre a sua qualidade, identificar vulnerabilidades e, se necessário, corrigir bugs. Outra mais valia é a rapidez no arranque dos projetos, uma vez que é possível escolher o conjunto de componentes mais adequados para os objetivos e, assim, ganhar tempo e reduzir custos numa fase inicial. O open source também aporta flexibilidade aos processos de desenvolvimento de software, cabendo ao utilizador decidir a melhor forma de incorporar os componentes no seu processo de desenvolvimento. Finalmente, mas não menos importante, há uma maior facilidade de evolução, pelo facto de não existir um contrato formal de utilização. Isto possibilita a substituição de um componente por outro equivalente com melhores características, ao longo da vida de um produto.
Em contrapartida, à medida que as organizações entregam mais software dependente deste modelo, também são impactadas por aspetos como a falta de suporte, seja por o projeto perder o suporte da comunidade ou por o mesmo ficar “órfão” (se o líder do projeto ou a comunidade adotar um projeto tecnologicamente mais interessante). Em adição, pela sua natureza transparente, o software de código aberto é alvo de análise constante de vulnerabilidades, pois se for detetada uma vulnerabilidade num componente muito utilizado, abre-se um vetor de potenciais ataques proporcional a essa utilização. Esta análise é efetuada por atores malignos, que tiram partido desse conhecimento, mas também por atores benignos, que divulgam à comunidade as vulnerabilidades encontradas, permitindo a sua correção o mais rapidamente possível. Neste modelo open source cabe à organização ter um conhecimento profundo dos componentes que utiliza com o detalhe sobre a versão exata de quais os componentes e o seu modelo de licenciamento. Idealmente, cada projeto de software deverá disponibilizar a sua Software Bill of Materials, de forma a que quando são divulgados relatórios de Common Vulnerability Exposure sobre um dado componente, possa ser avaliado o seu risco para os projetos que o utilizam, da forma mais automatizada possível.
Numa organização, foi possível observar a deteção automática de componentes considerados vulneráveis nos pacotes que são disponibilizados para passagem a produção (uma espécie de última linha de defesa) um processo simples, embora, eficaz. Idealmente, esta deteção de pacotes vulneráveis deve ser efetuada em tempo de desenvolvimento, para permitir a aplicação de medidas de mitigação antes do software ser disponibilizado para os ambientes de Qualidade ou Produção. Estas medidas de avaliação podem ser aplicadas sobre os pacotes de software produzidos ou diretamente sobre os repositórios de código utilizados.
A gestão do risco da miríade de componentes open source que são a base da maioria dos softwares contemporâneos é bastante exigente. No entanto, é possível lidar com essa complexidade, se existir essa preocupação nas organizações e forem utilizadas as ferramentas adequadas.