85 research outputs found
an analysis of security vulnerabilities in container images for scientific data analysis
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
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
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
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
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
- …