532 research outputs found

    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

    Software supply chain monitoring in containerised open-source digital forensics and incident response tools

    Get PDF
    Abstract. Legal context makes software development challenging for the tool-oriented Digital Forensics and Incident Response (DFIR) field. Digital evidence must be complete, accurate, reliable, and acquirable in reproducible methods in order to be used in court. However, the lack of sufficient software quality is a well-known problem in this context. The popularity of Open-source Software (OSS) based development has increased the tool availability on different channels, highlighting their varying quality. The lengthened software supply chain has introduced additional factors affecting the tool quality and control over the use of the exact software version. Prior research on the quality level has primarily targeted the fundamental codebase of the tool, not the underlying dependencies. There is no research about the role of the software supply chain for quality factors in the DFIR context. The research in this work focuses on the container-based package ecosystem, where the case study includes 51 maintained open-source DFIR tools published as Open Container Initiative (OCI) containers. The package ecosystem was improved, and an experimental system was implemented to monitor upstream release version information and provide it for both package maintainers and end-users. The system guarantees that the described tool version matches the actual version of the tool package, and all information about tool versions is available. The primary purpose is to bring more control over the packages and support the reproducibility and documentation requirement of the investigations while also helping with the maintenance work. The tools were also monitored and maintained for six months to observe software dependency-related factors affecting the tool functionality between different versions. After that period, the maintenance was halted for additional six months, and the tool’s current package version was rebuilt to limit gathered information for the changed dependencies. A significant amount of different built time and runtime failures were discovered, which have either prevented or hindered the tool installation or significantly affected the tool used in the investigation process. Undocumented, changed or too new environment-related dependencies were the significant factors leading to tool failures. These findings support known software dependency-related problems. The nature of the failures suggests that tool package maintainers are required to possess a prominent level of various kinds of skills for making operational tool packages, and maintenance is an effort-intensive job. If the investigator does not have similar skills and there is a dependency-related failure present in the software, the software may not be usable.Ohjelmistotoimitusketjun seuranta kontitetuissa avoimen lähdekoodin digitaaliforensiikan ja tietoturvapoikkeamien reagoinnin työkaluissa. Tiivistelmä. Oikeudellinen asiayhteys tekee ohjelmistokehityksestä haasteellista työkalupainotteiselle digitaaliforensiikalle ja tietoturvapoikkeamiin reagoinnille (DFIR). Digitaalisen todistusaineiston on oltava kokonaista, täsmällistä, luotettavaa ja hankittavissa toistettavilla menetelmillä, jotta sitä voidaan käyttää tuomioistuimessa. Laadun puute on kuitenkin tässä yhteydessä tunnettu ongelma. Avoimeen lähdekoodin perustuva ohjelmistokehitys on kasvattanut suosiotaan, mikä on luonnollisesti lisännyt työkalujen saatavuutta eri kanavilla, korostaen niiden vaihtelevaa laatua. Ohjelmistotoimitusketjun pidentyminen on tuonut mukanaan työkalujen laatuun ja täsmällisen ohjelmistoversion hallintaan vaikuttavia lisätekijöitä. Laatutasoa koskevassa aikaisemmassa tutkimuksessa on keskitytty pääasiassa työkalun olennaiseen koodipohjaan; ei sen taustalla oleviin riippuvuuksiin. Ohjelmistotoimitusketjun merkityksestä laadullisiin tekijöihin ei ole olemassa tutkimusta DFIR-asiayhteydessä. Tämän työn tutkimuksessa keskitytään konttipohjaiseen pakettiekosysteemiin, missä tapaustutkimuksen kohteena on 51 ylläpidettyä avoimen lähdekoodin DFIR-työkalua, jotka julkaistaan ns. OCI-kontteina. Työssä parannettiin pakettiekosysteemiä ja toteutettiin kokeellinen järjestelmä, jolla seurattiin julkaisuversiotietoja ja tarjottiin niitä sekä pakettien ylläpitäjille että loppukäyttäjille. Järjestelmä takaa, että kuvattu työkaluversio vastaa työkalupaketin todellista versiota, ja kaikki tieto työkaluversioista on saatavilla. Ensisijaisena tarkoituksena oli lisätä ohjelmistopakettien hallintaa ja tukea tutkintojen toistettavuus- ja dokumentointivaatimusta, kuten myös auttaa pakettien ylläpitotyössä. Työssä myös seurattiin ja ylläpidettiin työkaluja kuuden kuukauden ajan sellaisten ohjelmistoriippuvuuksien aiheuttamien tekijöiden tunnistamiseksi, jotka vaikuttavat työkalun toimivuuteen eri versioiden välillä. Lisäksi odotettiin vielä kuusi kuukautta ilman ylläpitoa, ja työkalun nykyinen pakettiversio rakennettiin uudelleen, jotta kerätty tieto voitiin rajoittaa vain muuttuneisiin riippuvuuksiin. Työn aikana löydettiin huomattava määrä erilaisia rakennusaika- ja suoritusaikavirheitä, mitkä ovat joko estäneet tai haitanneet työkalun asennusta, tai muuten vaikuttaneet merkittävästi tutkinnassa käytettyyn työkaluun. Dokumentoimattomat, muuttuneet tai liian uudet ympäristöriippuvuudet olivat merkittäviä työkaluvirheisiin johtaneita tekijöitä. Nämä löydökset tukevat ennestään tunnettuja ohjelmistoriippuvuusongelmia. Virheiden luonteesta voidaan päätellä, että työkalujen ylläpitäjiltä vaaditaan paljon erilaista osaamista toiminnallisten työkalupakettien ylläpitämisessä, ja ylläpitäminen vaatii paljon vaivaa. Jos tutkijalla ei ole vastaavia taitoja ja ohjelmistossa on riippuvuuksiin liittyvä virhe, ohjelmisto saattaa olla käyttökelvoton
    corecore