Standardisierte Security Scans für CI/CD Pipelines

Standardisierte Security Scans für CI/CD Pipelines

von Michael Wager

Viele Unternehmen, gerade größere Unternehmen mit einer Vielzahl von Entwicklungsteams, sind tagtäglich mit den Herausforderungen moderner Softwareentwicklung konfrontiert: Fehlende Standardisierung macht Tooleinbindung und Wartung zu umständlichen und zeitfressenden Aufgaben. Dieses Problem fehlender Standardisierung in der Integration betrifft auch die zunehmende Zahl an Security-Tools, die für verschiedene Aufgaben wie Code security, Software Composition Analasys (SCA) oder Infrastructure-as-code Scans (IaC) eingesetzt werden. Unterschiedliche Versionen der Tools, individuelle Konfigurationen und fehlende zentrale Steuerung erschwerten die konsistente Einhaltung von Sicherheitsvorgaben und die Integration der Ergebnisse in das zentrale Schwachstellenmanagement-System, in diesem Fall DefectDojo (mehr dazu hier). Aus diesem Grund haben wir dafür eine standardisierte, wartbare und sichere Lösung basierend auf Docker-Images (Distroless Chainguard-Images) geschaffen. Schauen wir uns diese Probleme und Tools genauer an:

Die Probleme

Keine Standardisierung: Teams setzten verschiedene Versionen und Konfigurationen der Tools ein, was zu Inkonsistenzen und Mehraufwand führte

Fehlende Automatisierung: Ergebnisse der Scans mussten manuell verarbeitet werden, um sie in DefectDojo zu importieren

Komplexität für Teams: Die manuelle Einrichtung und Pflege der Tools in den CICD-Pipelines war zeitaufwändig, fehleranfällig und nicht skalierbar

Austauschbarkeit: Im Falle der Einführung eines neuen Tools müssten alle Konfigurationen angepasst werden

Unsere Lösung

Wir haben eine zentralisierte, standardisierte Lösung entwickelt, die für alle Teams zugänglich und einfach zu nutzen ist.

1. Docker-basierte Komponenten:

Wir haben drei standardisierte Docker-Images entwickelt für:

• Code Security Scans (SAST & SCA)

• Container Image Scans

• Infrastructure-as-Code (IaC) Scans


Die Docker-Images funktionieren distroless und werden regelmäßig automatisiert gebaut, sowie auf deren Funktionalität & Sicherheit getestet, um stets die aktuellsten Versionen der Tools bereitzustellen. Alle Images werden in einem zentralen, Nexus-gehosteten Repository gepflegt und sind somit compliant mit den internen Richtlinien für Container Images.

2. Einfache Integration in GitLab:

Die Lösung wurde als GitLab-Komponenten entwickelt. Teams können einfach ein include-Statement in ihrer Pipeline hinzufügen und nur wenige Parameter konfigurieren – der Rest läuft automatisch.

• Ergebnisse der Scans werden direkt in DefectDojo importiert, sodass keine manuelle Nacharbeit nötig ist

• Die Ausführung ist vollständig compliant und ermöglicht Custom Logic für Management-Reports

• Aufgrund der Nähe zur Quelle (Source Code Respository, Image) bietet dies auch weitere Möglichkeiten in Zukunft wie zb KI-basierte Reachability-Analyse der extenen Dependencies & Komponenten

3. Flexible Unterstützung für andere CICD-Systeme:

Neben GitLab unterstützen wir dadurch z.b. auch Jenkins oder Azure für Teams, die andere Pipelines nutzen.

4. Inner-Source-Kollaboration:

Das Projekt wurde gemeinsam mit den Security Champions als Inner-Source-Projekt im Konzern-GitLab entwickelt.

• Das Repository ist public für alle Entwickler im Konzern

• Contributions via Merge Requests ermöglichen eine ständige Verbesserung der Lösung

Die Vorteile für Teams und das Management

Zeitersparnis: Teams müssen nur unsere standardisierte Lösung integrieren und profitieren von vorgefertigten, getesteten Images die „einfach funktionieren“

Sicherheit: Automatisiertes Testing, Distroless, aktuelle Tool-Versionen und compliance-gerechte Scans sorgen für hohe Sicherheit

Transparenz: Zentrale Ergebnisse und einheitliches Reporting ermöglichen ein besseres Management von Schwachstellen

Kollaboration: Inner-Source fördert den Austausch und die Weiterentwicklung durch die gesamte Organisation

Modularität: Wir können jederzeit Tools austauschen oder weitere Tools hinzufügen und einfach einen neuen Release machen. Teams erhöhen die Version und erhalten das aktuellste Image

Fazit

Die Bereitstellung von einfach in die Pipelines zu integrierenden Containern vereinfacht die Sicherheitsarbeit der Teams erheblich und bietet gleichzeitig dem Management die notwendige Transparenz und Kontrolle. Mit einem einzigen Include-Statement erhalten Teams eine standardisierte, sichere und zukunftsfähige Lösung für ihre Security Scans.


Haben Sie ähnliche Herausforderungen? Kontaktieren Sie uns und lassen Sie uns gemeinsam an einer sicheren Zukunft arbeiten!

Jetzt kontaktieren!

Continuous Security Monitoring using a Vulnerability Heatmap

Continuous Security Monitoring using a Vulnerability Heatmap

by Michael Wager

In the dynamic world of software development, ensuring the security of applications is an ongoing process, not a one-time event. The rise of DevSecOps underscores the importance of integrating security practices within the development lifecycle. One critical challenge in this landscape is the sheer volume and variety of vulnerabilities identified through different scanning tools, such as Static Application Security Testing (SAST), Software Composition Analysis (SCA), or container image scans. It’s crucial for both technical and non-technical stakeholders to understand that security is not a „set it and forget it“ task. New vulnerabilities, especially those arising from the supply chain of software products (like the infamous Log4j), can emerge at any time. This reality necessitates continuous monitoring and remediation efforts.

To address this challenge, our team at secureIO has developed a vulnerability heatmap as an open source project on GitHub. This tool provides a visual representation of vulnerabilities over time, making it easier for non-technical stakeholders to grasp the ongoing nature of security risks and the efforts required to mitigate them.

Introducing the Vulnerability Heatmap

Our Vulnerability Heatmap, detailed in our GitHub repository and available for demonstration here, is designed to offer clear insights into the status of application vulnerabilities. It serves (or soon will serve) multiple purposes, such as:

  • Visualizing the number of vulnerabilities: It provides a quantitative view of open vulnerabilities per application, helping stakeholders understand the scope of security issues.
  • Highlighting critical vulnerabilities: By showing the most critical and high-risk vulnerabilities found in applications, it enables focused remediation efforts.
  • Tracking SLA compliance: The heatmap can visualize the status of applications according to their Service Level Agreements (SLAs), prioritizing remediation tasks based on agreed timelines.
  • Combining SLA and Exploit Prediction Scoring System (EPSS): This view helps assess the likelihood of exploitability, providing a realistic view of potential security risks.
  • Application-specific insights: It offers a detailed view of vulnerabilities for specific applications, facilitating targeted security measures.

Our heatmap is designed to serve the needs of various stakeholders within an organization, offering the flexibility to extract the precise information each group requires:

  • Upper Management (UM): They require a summary of security risks, potential business impacts, and estimated mitigation costs to make strategic decisions.
  • App Management (AM): This group needs a summary of vulnerabilities by module to manage project schedules and resource allocation.
  • App Teams and DevOps (AT): They focus on specific vulnerability details to prioritize fixes and improvements in the code.
  • Product Security Team (PS): Responsible for identifying and assessing vulnerabilities, they use the heatmap to ensure compliance with SLAs and manage overall risk.
  • Vendors (VE): They track open tickets and perform regular security assessments, using the heatmap to monitor their tasks.
  • Security Champions (SC): These stakeholders stay updated on new vulnerabilities and security trends, leveraging the heatmap for continuous improvement in security practices.
  • Regulatory Entities (TG): They require visibility into the level of application security and the measures taken to protect data, ensuring compliance with regulations.

Data Source

The data of the vulnerabilities is coming from DefectDojo, an open-source application vulnerability management tool we also contributed to. A nightly import job fetches data from the DefectDojo API, normalizes it to a unified data structure and stores it into a MongoDB. When the frontend wants to display the data, a simple node.js service is then able to fetch the data fast from MongoDB in order to support realtime visualization.

Conclusion

We are just getting started with our Vulnerability Heatmap, but we are convinced that it can be a vital tool in the modern application security toolkit. By visualizing vulnerabilities and tracking remediation efforts over time, it supports the continuous nature of security monitoring essential in today’s fast-paced development environments and it also bridges the gap between technical and non-technical stakeholders.

Visit our GitHub repository for more details and check out the demo to see the heatmap in action. Our goal at secureIO is to make software safer, one vulnerability at a time!

Try it out!

Leveraging OWASP DefectDojo for Enhanced Vulnerability Management 

Leveraging OWASP DefectDojo for Enhanced Vulnerability Management 

Von Michael Wager 

As cybersecurity threats continue to evolve, the need for robust vulnerability management tools has never been greater. One such powerful open-source tool is OWASP’s DefectDojo. At secureIO, we do not only use DefectDojo to manage and track vulnerabilities, but we also actively contribute to its development. This blog post will introduce the features of the tool and also highlight our recent contributions. 

What is OWASP DefectDojo? 

OWASP DefectDojo is an open-source application vulnerability management tool that helps security teams track, manage, and report on vulnerabilities discovered in their environments. It simplifies the complex process of vulnerability tracking and provides valuable insights through comprehensive dashboards and reports. Key features include: 

  • Centralized vulnerability management: Results of scanner, manual Penetration-Tests etc will be imported centrally 
  • Detailed reporting and analytics: be able to quickly communicate a products security stance 
  • Integrations with various scanning tools: supports >170 Scanners out of the Box (like Checkmarx, Nessus, BurpSuite, etc.) 
  • Role-based access control 
  • Risk acceptance: change status of findings (e.g. false positives, accept risk etc) 
  • Deduplication: compares findings to automatically identify duplicates 
  • Service Level Agreement (SLA): allows you to maintain your security SLAs and automatically remind teams whenever a SLA is about to get breached, or is breached 

Our Contributions to DefectDojo 

secureIO is always trying to give back to the community, that’s why we have a public GitHub Organization where all our open-source projects are hosted. See github.com/secureIO-GmbH.  

After introducing and setting up DefectDojo for a large enterprise customer, we found that it did not support a certain scanner used by their teams, so we quickly aligned with the OWASP community and created a pull request to create a new Parser: https://github.com/DefectDojo/django-DefectDojo/pull/10522. This parser enhances the tool’s ability to interpret and import findings from an additional security scanner called Kiuwan, further expanding its versatility and usability. 

More Open Source Engagement at secureIO 

Some months ago, we also started our own open-source project: Vulnerability-Heatmap. The idea comes from the need to visualize security vulnerabilities across multiple projects in a heatmap representation. The orchestration and tracking has become quite complex, especially for central security teams in large enterprises dealing with a multitude of distributed teams. The heatmap is built for the ease of adaptation by technology management and development roles to identify the critical outliers within the organization. The different views of the heatmap allow tailored representation of configurable criteria over time and across projects. The Vulnerability Heatmap is particularly helpful for Security Awareness and Security Champions programs by giving an easy consumable representation of the enterprise’s flaws. Best-practice guidance for incorporation in your Awareness program will be referenced in the future. 

As this project is open source anyway, we had the idea of putting it into DefectDojo, but we are still in contact with its maintainers. They currently have a feature freeze because v3 will be rolled out soon

Conclusion 

At secureIO, we are committed to enhancing the tools and resources available to the cybersecurity community. Our contributions to OWASP DefectDojo reflect our dedication to improving security and helping the community.   

Stay tuned for more updates as we continue to innovate and contribute to the open-source cybersecurity ecosystem. 

Feel free to reach out to us if you have any questions or need help integrating these tools into your security workflow. We are always here to help you enhance your cybersecurity defenses! 

Secure containers – Do component reduction strategies fix your container security nightmares?

Secure containers – Do component reduction strategies fix your container security nightmares?

by Michael Wager
Recently we gave a talk at the BSides Conference in Munich. Container security is an ongoing concern for organizations. Often seen as a „black box,“ containers pose challenges in addressing vulnerabilities, especially when base image updates are not readily available. Security scanners detect numerous findings, and even critical issues can be hard to resolve. In our exploration, we delve into practical approaches and best practices to minimize your container’s attack surface and also share some insights into our scientific research project collaboration with the University of Applied Sciences, Augsburg. We guide you on the journey to strip away unnecessary components, moving towards fully distroless containers. We also examine whether the „distroless“ concept offers a solution to your security concerns, shedding light on expectations, challenges, and potential outcomes.
You can find the slides here.

Neuerungen der ISO/IEC 27001 und ISO/IEC 27002

Neuerungen der ISO/IEC 27001 und ISO/IEC 27002

von Dominik Weyand

Anpassung der Normen

Seit der letzten Revision sind die Cybergefahren stark angestiegen, die Anforderungen an den Datenschutz wurden verschärft und die technische Entwicklung ist vorangeschritten. Aus diesen Gründen war es notwendig die Anforderungen an die ISO/IEC 27002 sowie an die ISO/IEC 27001 von Grund auf zu überarbeiten. Diese Anpassungen wurden in Form der ISO/IEC 27001:2022 und der ISO/IEC 27002:2022 bereits veröffentlicht.

Änderungen durch die Revision

Die wesentlichen Änderungen beziehen sich auf die inhaltliche Umstrukturierung der ISO/IEC 27002. Vergleicht man die beiden Gliederungen, so ist schnell erkennbar, dass in dem neuen Standard aus 114 Maßnahmen in 14 Bereichen 93 Maßnahmen in 4 Bereichen geworden sind. Die Reduzierung ist dadurch erklärbar, dass bestimmte Inhalte zusammengefasst, allerdings nicht weggefallen sind. Zusätzlich gibt es 11 neue Maßnahmen, welche in dieser Form im vorherigen Standard nicht existieren. Weiterhin wird in der neuen Version das Ziel jeder Maßnahme explizit definiert und durch weitere Informationen spezifiziert. Die folgenden 11 neuen Maßnahmen wurden aufgenommen, um aktuelle Entwicklungen in der Informationssicherheit zu berücksichtigen:

5.7 Bedrohungsintelligenz Organisatorische Maßnahme
5.23 Informationssicherheit für die Nutzung von Cloud-Diensten Organisatorische Maßnahme
5.30 IKT-Bereitschaft für Geschäftskontinuität Organisatorische Maßnahme
7.4 Überwachung der physischen Sicherheit Physische Maßnahme
8.9 Konfigurationsmanagement Technologische Maßnahme
8.10 Löschung von Informationen Technologische Maßnahme
8.11 Datenmaskierung Technologische Maßnahme
8.12 Verhinderung von Datenverlusten Technologische Maßnahme
8.16 Überwachungstätigkeiten Technologische Maßnahme
8.23 Web-Filterung Technologische Maßnahme
8.28 Sichere Kodierung Technologische Maßnahme

Hierbei muss beachtet werden, dass nicht einfach alle Maßnahmen aus dem Anhang abgearbeitet werden sollen, sondern die Risiken aus der jeweiligen Unternehmensperspektive zu betrachten sind. Die neue Version fordert also, dass dem Blick in den Normenkontext der Blick auf die Situation und die Bedürfnisse des Unternehmens vorausgehen muss. Auf dieser Grundlage müssen die Risiken analysiert und Maßnahmen für das Unternehmen abgleitet werden.
Neben den signifikanten Änderungen des Anhangs wurden auch einige Stellen in der Norm angepasst. So wurden beispielsweise in den Kapiteln einzelne Anforderungen umformuliert oder durch zusätzliche Aufzählungspunkte ergänzt. Darüber hinaus wurde das Unterkapitel 9.3 Managementbewertung stärker untergliedert, um die Bedeutung dieser hervorzuheben. Ebenso wurde die Reihenfolge in Kapitel 10 Verbesserung getauscht, wodurch die fortlaufende Verbesserung vor den Umgang mit Nichtkonformitäten und Korrekturmaßnahmen gestellt wird.

 

Handlungsbedarf

Die neuen Anpassungen im Anhang sorgen dafür, dass das Informationssicherheitsmanagement gemäß ISO/IEC 27001 mit anderen Managementsystemen zu einem integrierten Managementsystem zusammengefügt werden kann und die Unternehmen somit von den Synergieeffekten profitieren. Auf Grund der stetig steigenden Anzahl an Anforderungen und Managementsystemen führt dies zu einer Reduzierung des operativen Aufwands. An erster Stelle sollen allerdings die zuvor genannten Änderungen bereits enthaltene Inhalte spezifizieren und keine grundlegend neuen Anforderungen an das Informationssicherheitssystem stellen. Während das Managementsystem also weitestgehend gleich bleibt, liegt die wirkliche Arbeit beim Umstieg auf die neue ISO 27001:2022 in der Umstellung der Risikoanalyse auf die neuen Controls. Die Übergangsfrist für die Umstellung auf die neue Version beläuft sich gemäß den Vorgaben des International Accreditation Forum (IAF) auf den 31.10.2025. Unternehmen, die vor einer Rezertifizierung stehen, können bis zu diesem Zeitpunkt entscheiden, ob sie nach dem bisherigen oder dem neuen Standard zertifiziert werden. Für Unternehmen, die neu anfangen ist es ratsam sich direkt an der Version 2022 zu orientieren. Somit lässt sich festhalten, dass sich der Umfang der Änderungen für bereits zertifizierte Unternehmen im Rahmen hält und diese besser gleich umgesetzt werden sollen. Der Aufwand für Unternehmen, die bislang die Punkte des Anhangs lediglich abgehakt haben ist jedoch um ein vielfaches höher. Insbesondere die Überarbeitung der SoA (Statement of Applicability), welche die Maßnahmen zur Behandlung von Risiken auflistet und beschreibt, nimmt einige Zeit in Anspruch. Ebenso müssen die in der Risikoanalyse festgestellten Risiken mit wirksamen Maßnahmen verknüpft werden. Darüber hinaus ist es wichtig alle in der Norm enthaltenen Anforderungen zu bearbeiten. Sollten bestimmte Anforderungen nicht zum Unternehmen passen muss hierzu eine Begründung abgegeben werden, weshalb diese nicht für das Unternehmen relevant sind.
Abschließend ist zu beachten, dass die tatsächlichen Auswirkungen der Revision auf Unternehmen von verschiedenen Faktoren abhängig sind. Daher wird empfohlen, sich mit einem Experten für Informationssicherheit Verbindung zu setzen, um die genauen Auswirkungen der ISO 27001:2022 auf Ihr Unternehmen zu ermitteln und geeignete Maßnahmen umzusetzen.