85 research outputs found

    an analysis of security vulnerabilities in container images for scientific data analysis

    Get PDF
    Software containers greatly facilitate the deployment and reproducibility of scientific data analyses on high-performance computing clusters (HPC). However, container images often contain outdated or unnecessary software packages, which increases the number of security vulnerabilities in the images and widens the attack surface of the infrastructure. This thesis presents a vulnerability analysis of container images for scientific data analysis. We compare results obtained with four vulnerability scanners, focusing on the use case of neuroscience data analysis, and quantifying the effect of image update and minification on the number of vulnerabilities. We find that container images used for neuroscience data analysis contain hundreds of vulnerabilities, that software updates remove about two thirds of these vulnerabilities, and that removing unused packages is also effective. We conclude with recommendations on how to build container images with a reduced amount of vulnerabilities

    Development of an ERP with CI/CD application, Authentication and System Auditing

    Get PDF
    Developing and maintaining software like ERPs can be challenging because of the complexity and the amount of data that these systems require maintaining. Many of the software programs can grow with weak structure, which lead to great effort to maintain, and with more probability to error. This project proposes that a development cycle that incorporates DevOps can have major bene ts, by not only removing some hassle the programmers and systems admins have with testing and deploying the system, but can also give a early feedback if the changes made into the application brings problems to the systems. The design of a CI/CD pipeline and audit logs, and the implementation in an ERP development helped get more feedback and cause of root problems, which lead to more confidence in the developers to make changes, and to escalate more quickly since the deployment is automatized.Desenvolver "software" como os ERPs podem ser difícil de manter devido à complexidade e a quantidade de dados envolvida nestes sistemas. Isto leva a que muitos destes "softwares" cresçam com uma estrutura de código fraca, o que leva a um esforço adicional para manter, e com maior probabilidade para erros. Este projeto propõe que a incorporação do conceito de DevOps no ciclo de desenvolvimento traz muitas vantagens, não só a remover algum trabalho dos programadores e dos administradores de sistemas ao ser mais fácil testar o sistema e fazer deploy do mesmo, mas também fornece uma forma de feedback mais rápida para eventuais erros. O "design" de uma pipeline CI/CD e logs para auditoria do sistema, e a respetiva implementação destes conceitos no desenvolvimento consegue dar mais feedback a problemas, o que leva a uma maior confiança dos programadores para fazer alterações, e conseguir escalar a solução mais rapidamente visto que a implantação é automatizada

    Security assessment of open source third-parties applications

    Get PDF
    Free and Open Source Software (FOSS) components are ubiquitous in both proprietary and open source applications. In this dissertation we discuss challenges that large software vendors face when they must integrate and maintain FOSS components into their software supply chain. Each time a vulnerability is disclosed in a FOSS component, a software vendor must decide whether to update the component, patch the application itself, or just do nothing as the vulnerability is not applicable to the deployed version that may be old enough to be not vulnerable. This is particularly challenging for enterprise software vendors that consume thousands of FOSS components, and offer more than a decade of support and security fixes for applications that include these components. First, we design a framework for performing security vulnerability experimentations. In particular, for testing known exploits for publicly disclosed vulnerabilities against different versions and software configurations. Second, we provide an automatic screening test for quickly identifying the versions of FOSS components likely affected by newly disclosed vulnerabilities: a novel method that scans across the entire repository of a FOSS component in a matter of minutes. We show that our screening test scales to large open source projects. Finally, for facilitating the global security maintenance of a large portfolio of FOSS components, we discuss various characteristics of FOSS components and their potential impact on the security maintenance effort, and empirically identify the key drivers

    Secrets Revealed in Container Images: An Internet-wide Study on Occurrence and Impact

    Full text link
    Containerization allows bundling applications and their dependencies into a single image. The containerization framework Docker eases the use of this concept and enables sharing images publicly, gaining high momentum. However, it can lead to users creating and sharing images that include private keys or API secrets-either by mistake or out of negligence. This leakage impairs the creator's security and that of everyone using the image. Yet, the extent of this practice and how to counteract it remains unclear. In this paper, we analyze 337,171 images from Docker Hub and 8,076 other private registries unveiling that 8.5% of images indeed include secrets. Specifically, we find 52,107 private keys and 3,158 leaked API secrets, both opening a large attack surface, i.e., putting authentication and confidentiality of privacy-sensitive data at stake and even allow active attacks. We further document that those leaked keys are used in the wild: While we discovered 1,060 certificates relying on compromised keys being issued by public certificate authorities, based on further active Internet measurements, we find 275,269 TLS and SSH hosts using leaked private keys for authentication. To counteract this issue, we discuss how our methodology can be used to prevent secret leakage and reuse.Comment: 15 pages, 7 figure

    Learning from, Understanding, and Supporting DevOps Artifacts for Docker

    Full text link
    With the growing use of DevOps tools and frameworks, there is an increased need for tools and techniques that support more than code. The current state-of-the-art in static developer assistance for tools like Docker is limited to shallow syntactic validation. We identify three core challenges in the realm of learning from, understanding, and supporting developers writing DevOps artifacts: (i) nested languages in DevOps artifacts, (ii) rule mining, and (iii) the lack of semantic rule-based analysis. To address these challenges we introduce a toolset, binnacle, that enabled us to ingest 900,000 GitHub repositories. Focusing on Docker, we extracted approximately 178,000 unique Dockerfiles, and also identified a Gold Set of Dockerfiles written by Docker experts. We addressed challenge (i) by reducing the number of effectively uninterpretable nodes in our ASTs by over 80% via a technique we call phased parsing. To address challenge (ii), we introduced a novel rule-mining technique capable of recovering two-thirds of the rules in a benchmark we curated. Through this automated mining, we were able to recover 16 new rules that were not found during manual rule collection. To address challenge (iii), we manually collected a set of rules for Dockerfiles from commits to the files in the Gold Set. These rules encapsulate best practices, avoid docker build failures, and improve image size and build latency. We created an analyzer that used these rules, and found that, on average, Dockerfiles on GitHub violated the rules five times more frequently than the Dockerfiles in our Gold Set. We also found that industrial Dockerfiles fared no better than those sourced from GitHub. The learned rules and analyzer in binnacle can be used to aid developers in the IDE when creating Dockerfiles, and in a post-hoc fashion to identify issues in, and to improve, existing Dockerfiles.Comment: Published in ICSE'202
    • …
    corecore