02_P1008_Leistungsbeschreibung_V 1.0.pdf

Projekt 1008

KI im Secure Software

Development Life Cycle (KISDL)

Leistungsbeschreibung

und Besondere Bewerbungsbedingungen

Version: 1.0

Datum: 03.08.2026

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Internet: https://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2026

Bundesamt für Sicherheit in der Informationstechnik 2

Inhaltsverzeichnis

Inhaltsverzeichnis

A Leistungsbeschreibung .................................................................................................................................................. 5

1 Übersichtsinformationen zum Projekt ................................................................................................................... 5

1.1 Auftraggeber (AG) .................................................................................................................................................................. 5

1.2 Ausgangslage und Handlungsbedarf ............................................................................................................................ 5

1.3 Auftragsgegenstand und Projektziele ........................................................................................................................... 6

1.4 Projektstrukturplan .............................................................................................................................................................. 8

2 Beschreibung der Arbeitspakete ................................................................................................................................ 9

2.1 Arbeitspaket 1: Auftaktbesprechung und Feinkonzept (Auftaktbesprechung)........................................... 9

2.2 Arbeitspaket 2: Ermittlung des Forschungs- und Markstandes zum Thema KI im SSDLC, Vergleich der Methoden und Veröffentlichung der Ergebnisse (Studie zu KI im SSDLC) .......................................................... 9

2.3 Arbeitspaket 3: Erarbeitung von Best Practices zum Einsatz ausgewählter Tools im SSDLC und Erstellung eines Proof of Concepts (Best Practices und PoC)........................................................................................... 11

2.4 Arbeitspaket 4: Zwischenworkshop zur Vorstellung bisheriger Ergebnisse und Feinkonzept (Zwischenworkshop) ......................................................................................................................................................................... 12

2.5 Arbeitspaket 5 (OPTIONAL): Einordnung und Empfehlungen für AVA-Bepunktung in den Common Criteria (Aktualisierung Einordnung CC-Bewertungsmetrik) .................................................................... 12

2.6 Arbeitspaket 6 (OPTIONAL): Erstellung einer Guideline für den Einsatz von KI-Tools mit Dual-Use in Prüfstellen und ggf. bei Herstellern (Guideline: KI-Tools in der Evaluierung in Prüfstellen) ....................... 14

2.7 Arbeitspaket 7 (OPTIONAL): Erstellung einer Referenzarchitektur für die Integration von KI-Tools des SSDLC in Open CoDE (Referenzarchitektur KI-Tools im SSDLC in Open CoDE) ........................................... 15

2.8 Arbeitspaket 8 (OPTIONAL): Abschlusspräsentation der Projektergebnisse und Abschlussbericht (Abschlussworkshop) ......................................................................................................................................................................... 16

3 Zahlungs- und Meilensteinplan, Projektplan und Vergütung .................................................................... 18

3.1 Vergütung ............................................................................................................................................................................... 18

3.1.1 Vergütung von AP nach Festpreis ........................................................................................................................... 18

3.1.2 Vergütung von AP nach Aufwand .......................................................................................................................... 18

3.1.2.1 Personalkosten ................................................................................................................................................... 18

3.1.2.2 Lizenzkosten ....................................................................................................................................................... 19

3.2 Projektverlauf, Zahlungs- und Meilensteinplan .................................................................................................... 20

4 Rahmen- und Ausführungsbedingungen ............................................................................................................ 22

4.1 Personal des Auftragnehmers ........................................................................................................................................ 22

4.1.1 Direktionsrecht und Disziplinargewalt ................................................................................................................ 22

4.1.2 Qualifikationen, Erfahrungen und sonstige Anforderungen ...................................................................... 22

4.1.3 Personaleinsatz und -austausch ............................................................................................................................... 23

4.2 Projektorganisation und Erreichbarkeit .................................................................................................................... 23

4.3 Projektsprache ...................................................................................................................................................................... 24

4.4 Besprechungen ..................................................................................................................................................................... 24

4.5 Berichtswesen ....................................................................................................................................................................... 24

Bundesamt für Sicherheit in der Informationstechnik 3

Fehler! Kein Text mit angegebener Formatvorlage im Dokument.

4.6 Formale Anforderungen an Projektdokumente .................................................................................................... 24

4.7 Barrierefreie Gestaltung ................................................................................................................................................... 25

4.8 Verschlüsselung der Kommunikation ........................................................................................................................ 26

4.9 Berechtigte Interessen des Herstellers ....................................................................................................................... 26

4.10 Einsatz von Unterauftragnehmern .............................................................................................................................. 26

4.11 Anforderungen an die Rechnungsstellung ............................................................................................................... 26

4.11.1 Zeitpunkt ........................................................................................................................................................................... 26

4.11.2 Elektronische Form ....................................................................................................................................................... 27

4.12 Nachhaltige Umsetzung der Leistung ........................................................................................................................ 27

B Besondere Bewerbungsbedingungen .................................................................................................................... 28

5 Bedingungen für die Zuschlagserteilung ............................................................................................................. 28

5.1 Gesetzliche Ausschlussgründe, Eignung und Ausführungsbedingungen ................................................... 28

5.2 Wirtschaftlichstes Angebot ............................................................................................................................................. 28

5.2.1 Bewertungspreis ............................................................................................................................................................. 29

5.2.2 Leistung .............................................................................................................................................................................. 29

5.2.3 Erweiterte Richtwertmethode mit dem Entscheidungskriterium „Leistungspunkte“ ..................... 30

6 Erstellung des Angebots .............................................................................................................................................. 31

6.1 Angebotsformular ............................................................................................................................................................... 31

6.2 Anlagen zum Angebotsformular .................................................................................................................................. 31

6.2.1 Anlage: Angebotsangaben gemäß den Besonderen Bewerbungsbedingungen ................................... 32

6.2.1.1 Einzelbieter / Mitglieder der Bietergemeinschaft ............................................................................... 32

6.2.1.2 Unterauftragnehmer ....................................................................................................................................... 32

6.2.1.3 Eignungskriterien ............................................................................................................................................. 33

6.2.1.4 Qualitative Zuschlagskriterien .................................................................................................................... 36

6.2.2 Anlage: Bietergemeinschaftserklärung ................................................................................................................. 44

6.2.3 Anlage: Unterauftragnehmerverpflichtungserklärung(en) .......................................................................... 44

6.2.4 Anlage: Angaben zu vorliegenden Ausschlussgründen und zur Selbstreinigung im Sinne von § 125 GWB ......................................................................................................................................................................... 45

C Abkürzungsverzeichnis ............................................................................................................................................... 46

D Muster Leistungsnachweis ......................................................................................................................................... 47

4 Bundesamt für Sicherheit in der Informationstechnik

A Leistungsbeschreibung

1 Übersichtsinformationen zum Projekt

1.1 Auftraggeber (AG)

Als die Cybersicherheitsbehörde des Bundes gestaltet das Bundesamt für Sicherheit in der Informationstechnik (BSI) Informationssicherheit in der Digitalisierung durch Prävention, Detektion und Reaktion für Staat, Wirtschaft und Gesellschaft.

Das BSI wurde am 1. Januar 1991 gegründet und gehört zum Geschäftsbereich des Bundesministeriums des Innern. Derzeit sind dort ca. 1.650 Mitarbeitende beschäftigt. Seinen Hauptsitz hat das BSI in Bonn.

Das BSI ist die zentrale, unabhängige und neutrale Stelle für Fragen zur IT-Sicherheit. Das BSI schützt die Netze des Bundes; es richtet sich jedoch zugleich auch an gewerbliche und private Anbieter wie Nutzer von Informationstechnik. Das breite Aufgabenspektrum des BSI ist im BSI-Gesetz geregelt.

1.2 Ausgangslage und Handlungsbedarf

Methoden der Künstlichen Intelligenz (KI) zeigen in vielen Anwendungsbereichen erstaunliche Leistungen und werden zunehmend in Bereichen eingesetzt, die unser tägliches Leben beeinflussen. Auch das Gebiet der Cybersicherheit ist von KI nicht unberührt geblieben. Neue Tools werden beinahe täglich veröffentlicht, und vor allem Große KI-Sprachmodelle (LLMs) werden bereits heute zu diversen Anwendungszwecken eingesetzt. Die Bedrohungslage, z.B. durch Missbrauch von gutartig intendierten Modellen zu Angriffszwecken (Dual Use), wird dadurch stark verändert.

Da LLMs neben natürlichsprachlichen Texten häufig auch Code verarbeiten können, ist die Anwendung zur Codeanalyse naheliegend, z.B. um Schwachstellen zu identifizieren. Quellcode kann aus einer Vielzahl von Gründen Schwachstellen enthalten. So können menschliche Fehler und Unwissenheit die Ursache sein, Schwachstellen möglicherweise zum Zeitpunkt der Entwicklung noch nicht bekannt sein, oder auch Programmierassistenten unsicheren Code vorschlagen, der durch Entwickler unverändert übernommen wird. Werden die Schwachstellen ausgenutzt, können die Schäden verheerend sein. Aus diesem Grund ist es aus Sicht der Cybersicherheit wichtig, dass Code möglichst ohne Schwachstellen entwickelt wird und bestehende Schwachstellen möglichst frühzeitig detektiert und beseitigt werden. Zu diesem Zweck haben sich entsprechende Codeanalysetools im Kontext der Softwareentwicklung etabliert. Allerdings weisen die aktuell verfügbaren Tools einige Schwächen auf. So finden diese Tools häufig nur einen Teil der Schwachstellen, gehen mit hohen False-Positive-Raten einher, die zu hohem Arbeitsaufwand und niedriger Akzeptanz führen, und sind häufig nur von Experten produktiv nutzbar, da sie besondere Kenntnisse zur korrekten Interpretation und Weiterverarbeitung der Ergebnisse erfordern. Es stellt sich deshalb die Frage, inwiefern der Einsatz von KI diese Schwächen mildern oder ganz beseitigen kann.

Die Nutzung von LLMs im Secure Software Development Life Cycle (SSDLC) ist ein aktives Forschungsgebiet. Auch die Industrie ist hieran interessiert und beginnt, KI in derartige Produkte zu integrieren. Zurzeit existiert unseres Wissens nach kein Überblick über die tatsächlichen Fähigkeiten und Potenziale von LLMs in diesem Einsatzgebiet sowie der möglichen Veränderungen, die damit einhergehen (z.B. wie Angreifende durch den Einsatz solcher Tools gestärkt werden). Eine solche Einschätzung, basierend auf belastbaren Daten, ist allerdings essenziell, um beispielsweise geeignete Sicherheitsempfehlungen auszugeben. Zudem könnte ein solches Tool der produktiven Arbeit des BSI und der Bundesverwaltung zu Gute kommen, und die allgemeine Resilienz der Bundesverwaltung erhöhen, indem Schwachstellen schneller und einfacher analysiert und behoben werden können.

5 Bundesamt für Sicherheit in der Informationstechnik

Aufbauend auf dieser Ausgangslage zeigt sich ein Handlungsbedarf für das BSI, um seinem Anspruch gerecht zu werden, die aktuelle Cybersicherheitslage korrekt erfasst zu haben und Vorgänge auf der Basis fundierter Daten durchzuführen. Im Einzelnen sind folgende Aufgaben des BSI aus dem BSI-Gesetz (BSIG) hervorzuheben:

BSIG §3 Absatz 1 Satz 2 Ziffer 1: Gefahren für die Sicherheit in der Informationstechnik des Bundes abwehren;

BSIG §3 Absatz 1 Satz 2 Ziffer 2: Informationen über Sicherheitsrisiken und Sicherheitsvorkehrungen sammeln und auswerten und die gewonnenen Erkenntnisse anderen Stellen zur Verfügung stellen, soweit dies zur Erfüllung ihrer Aufgaben erforderlich ist, und Dritten zur Verfügung stellen, soweit dies zur Wahrung ihrer Sicherheitsinteressen erforderlich ist;

BSIG §3 Absatz 1 Satz 2 Ziffer 4: Sicherheitsrisiken bei der Anwendung der Informationstechnik sowie Entwicklung von Sicherheitsvorkehrungen untersuchen, insbesondere von informationstechnischen Verfahren und Geräten für die Sicherheit in der Informationstechnik (IT-Sicherheitsprodukte), soweit dies zur Erfüllung von Aufgaben des Bundes erforderlich ist, einschließlich der Forschung im Rahmen seiner gesetzlichen Aufgaben;

BSIG §3 Absatz 1 Satz 2 Ziffer 5: Kriterien, Verfahren und Werkzeuge für die Prüfung und Bewertung der Sicherheit von informationstechnischen Systemen oder Komponenten und für die Prüfung und Bewertung der Konformität im Bereich der IT-Sicherheit entwickeln;

BSIG §3 Absatz 1 Satz 2 Ziffer 8: Sicherheit von informationstechnischen Systemen oder Komponenten prüfen und bewerten sowie Sicherheitszertifikate erteilen;

BSIG §3 Absatz 1 Satz 2 Ziffer 15: IT-Sicherheitsprodukte und IT-Sicherheitsdienstleistungen für Einrichtungen der Bundesverwaltung bereitstellen;

BSIG §3 Absatz 1 Satz 2 Ziffer 17: Einrichtungen der Bundesverwaltung in Fragen der Informationssicherheit, einschließlich der Behandlung von Sicherheitsvorfällen, beraten und unterstützen sowie konkrete, praxisnahe Hilfsmittel zur Umsetzung von Informationssicherheitsvorgaben, insbesondere zur Umsetzung der Vorgaben nach den §§ 30 und 44, bereitstellen;

Die Ziele des Projekts kommen explizit diesem Handlungsbedarf nach. Um eine fundierte Einschätzung bezüglich der Fähigkeiten von KI im SSDLC zu erlangen, ist eine Studie über die schon erhältlichen Tools und die Fähigkeiten von KI-Modellen in diesem Gebiet notwendig. Des Weiteren kann auf Grundlage dieser Studie ein breiter Einsatz solcher Tools in der Bundesverwaltung vorbereitet, und der Einfluss auf Bewertungsprozesse, z.B. in der Zertifizierung, wo angenommen werden muss, dass auch bösartige Akteure diese Tools nutzen, ermittelt werden.

1.3 Auftragsgegenstand und Projektziele

Ziel des Projektes ist zunächst, den Stand der Technik im Bereich KI im SSDLC zu eruieren und eine vergleichende Marktübersicht der wichtigsten und leistungsstärksten Codeanalyse- und Hilfstools zu erstellen. Dabei sollen auch Tools berücksichtigt werden, die nicht vollständig auf KI basieren. Aufbauend auf den Ergebnissen dieser Studien soll einerseits der Bewertungsprozess im Rahmen der Softwarezertifizierung des BSIs an die festgestellten Fähigkeiten der Tools angepasst werden, und andererseits eine Referenzarchitektur für OpenCoDE erstellt werden, anhand derer eine Integration ausgewählter Tools in Open CoDE geplant werden kann. Im Einzelnen werden somit folgende Ziele verfolgt:

1. Erstellung einer Studie zum Stand der Technik und der Wissenschaft mit Marktübersicht und Analyse vorhandener Tools im SSDLC, mit Fokus auf Tools auf KI-Basis sowie Tools mit KI-Anteil.

Erstellung einer Übersicht über verfügbare Tools im SSDLC; hierbei sollen sowohl KI-basierte als auch hybride Ansätze mit KI-Anteil berücksichtigt und mindestens folgende Aspekte betrachtet werden:

6 Bundesamt für Sicherheit in der Informationstechnik

Funktionalitäten o Interpretierbarkeit des Outputs o Benötigtes Expertenwissen o Funktionsweise o Vertriebsmodelle o Open oder Closed Source o Einschätzung der Entwicklung auf diesem Feld in der nahen Zukunft (1-2 Jahre)

Erarbeitung von Bewertungskriterien, um Tools vergleichbar zu machen und ihre Leistungsfähigkeit einzuschätzen

Vergleich der Tools anhand der Bewertungskriterien

Begründete Vorauswahl der vielversprechendsten Tools mit Blick auf die folgenden Arbeitspakete und Vornehmen einer Detailbewertung für diese in der Praxis anhand repräsentativer Testfälle

Ableiten von Best Practices zur sicheren und zielführenden Nutzung der Tools

Zusammenfassung der Ergebnisse und Veröffentlichung in einer BSI-Publikation, die sich an Fachexperten aus dem Bereich von SSDLC und Codeanalyse richtet

2. Untersuchung der Anwendung von KI in der Schwachstellenidentifikation und Aktualisierung der Schwachstellenbewertungskriterien für Common Criteria (AVA-Tabelle) basierend auf empirischen Untersuchungen

• Erstellen von repräsentativen Testfällen, inklusive Durchführung empirischer Untersuchungen

• Aktualisierung der Schwachstellenbewertungskriterien basierend auf den Ergebnissen

• Auswertung der Änderung der Schwachstellenbewertungskriterien

• Empfehlungen für KI-Einsatz hinsichtlich Dual-Use Tools bei Prüfstellen und Herstellern in Form einer Guideline

3. Erarbeitung einer Referenzarchitektur zur Planung der Einführung von KI-Tools des SSDLC in Open CoDE1

Erweiterung der vorhandenen Architektur von OpenCoDE

Begründeter Vorschlag für die Auswahl der KI-Tools inkl. Kostenschätzung

Schätzung benötigter Hardware inkl. Kostenschätzung

Konzept zur Umsetzung/Integration in der Open CoDE Umgebung entwickeln und verschriftlichen

Erarbeitung eines möglichen Betriebsablaufs und Schätzung der Anschaffungs- und Betriebskosten

Die Ergebnisse müssen belastbar und für eine anschließende Vergabe geeignet sein.

1 www.opencode.de

Bundesamt für Sicherheit in der Informationstechnik 7

1.4 Projektstrukturplan

Im Rahmen der Leistungserbringung sind folgende Arbeitspakete (AP) vorgesehen:

AP 1: Auftaktbesprechung und Feinkonzept (Auftaktbesprechung)

AP 2: Ermittlung des Forschungs- und Markstandes zum Thema KI im SSDLC, Vergleich der Methoden und Veröffentlichung der Ergebnisse (Studie zu KI im SSDLC)

AP 3: Erarbeitung von Best Practices zum Einsatz ausgewählter Tools im SSDLC und Erstellung eines Proof of Concepts (Best Practices und PoC)

AP 4: Zwischenworkshop zur Vorstellung bisheriger Ergebnisse und Feinkonzept (Zwischenworkshop)

AP 5 (OPTIONAL): Einordnung und Empfehlungen für AVA-Bepunktung in den Common Criteria (Aktualisierung Einordnung CC-Bewertungsmetrik)

AP 6 (OPTIONAL): Erstellung einer Guideline für den Einsatz von KI-Tools mit Dual-Use in Prüfstellen und ggf. bei Herstellern (Guideline: KI-Tools in der Evaluierung in Prüfstellen)

AP 7 (OPTIONAL): Erstellung einer Referenzarchitektur für die Integration von KI-Tools des SSDLC in Open CoDE (Referenzarchitektur KI-Tools im SSDLC in Open CoDE)

AP 8: (OPTIONAL) Abschlusspräsentation der Projektergebnisse und Abschlussbericht (Abschlussworkshop)

AP 5, 6, 7 und 8 sind optionale Leistungen. Diese müssen vom Bieter angeboten werden, der AG verzichtet jedoch ggf. generell auf deren Beauftragung. Die Entscheidung wird durch den AG anhand der Zwischenergebnisse getroffen.

Die Beauftragung von AP 5 und 7 ist dabei abhängig von den Ergebnissen aus AP 2 und 3. Zeigen die Ergebnisse aus AP 2 keine nennenswerten Fähigkeiten oder Tools auf, erscheinen die Tools auch bei Befolgung der Best Practices aus AP 3 für einen sicheren und effizienten Einsatz im SSDLC ungeeignet oder wird der PoC aus AP 3 den zuvor im Anforderungskatalog definierten Anforderungen nicht gerecht, ist eine Weiterverwendung der Ergebnisse in AP 5 und AP 7 nicht sinnvoll und das Projekt wird nicht fortgeführt.

Sollte keines der AP 5, 6 und 7 durchgeführt werden, wird auch AP 8 nicht beauftragt, da sämtliche Ergebnisse bereits im Zwischenworkshop (AP 4) vorgestellt wurden.

Ein Anspruch auf Beauftragung der optionalen Arbeitspakete besteht nicht.

8 Bundesamt für Sicherheit in der Informationstechnik

2 Beschreibung der Arbeitspakete

Der Auftragnehmer (AN) hat die in den folgenden Arbeitspaketen dargestellten Leistungen zu erbringen.

2.1 Arbeitspaket 1: Auftaktbesprechung und Feinkonzept

(Auftaktbesprechung)

Zu Beginn des Projekts findet eine virtuelle Auftaktbesprechung zwischen AG und allen wesentlich am Projekt beteiligten Mitgliedern des Projektteams des AN statt. Die Auftaktbesprechung ist durch den AN nach Absprache mit dem AG in einem geeigneten Format zu organisieren. Es wird vorausgesetzt, dass sich die Teilnehmer vor der Besprechung umfassend mit dem Projekt auseinandergesetzt haben. Die Dauer sollte einen halben Arbeitstag nicht überschreiten. Von Seiten des AN sollten maximal 4 Personen teilnehmen.

In der Auftaktbesprechung wird vom AN das Vorgehen zu allen Arbeitspaketen im Detail vorgestellt. Verbleibende offene Fragen werden zwischen AG und AN diskutiert und verbindlich geklärt. Die Planung wird gegebenenfalls weiter konkretisiert und die Regeln der Zusammenarbeit verabschiedet. Hierbei liegt der Fokus auf AP 2, AP 3 und AP 4.

Ferner sind die generellen Kommunikationswege zu etablieren und die Erreichbarkeit der beteiligten Personen seitens AN und AG abzustimmen. Auch werden die Wege zur Übermittlung und Abstimmung von Projektinhalten, also von Dokumenten und sonstigen Leistungsgegenständen, abgesprochen.

Der AN erstellt ein Besprechungsprotokoll und legt dieses dem AG innerhalb von einer Woche nach der Besprechung vor. Kam es bei der Auftragserteilung zu zeitlichen Verschiebungen (vgl. Kapitel 6.2.1.4, Zuschlagskriterium „Zahlungs- und Meilensteinplan“) so werden die daraus ggf. resultierenden Terminverschiebungen verbindlich zwischen AN und AG abgestimmt. Der aktualisierte Zahlungs- und Meilensteinplan ist vom AN mit dem Besprechungsprotokoll vorzulegen.

2.2 Arbeitspaket 2: Ermittlung des Forschungs- und Markstandes

zum Thema KI im SSDLC, Vergleich der Methoden und

Veröffentlichung der Ergebnisse (Studie zu KI im SSDLC)

Der AN erstellt in diesem Arbeitspaket eine umfassende Studie zum aktuellen Stand der Technik im Bereich KI im SSDLC. Die Studie soll als Grundlage für die folgenden Arbeitspakete dienen, deshalb müssen die Inhalte mit Blick auf die Weiterverarbeitung erstellt werden. Der AN stimmt sich hierzu regelmäßig und anlassbezogen eng mit dem AG ab.

Im Einzelnen müssen mindestens folgende Punkte im Rahmen der Studie bearbeitet werden:

1. Der AN erstellt eine Übersicht über die am Markt erhältlichen Tools (einzelne Produkte) und Toolklassen (Kategorie, Sammlung von Tools mit derselben Zielsetzung) sowie über den aktuellen Forschungsstand zum Einsatz von KI im SSDLC. Es sollen hierbei auch hybride Ansätze betrachtet werden. Dabei muss auf diverse Aspekte der Tools und Toolklassen eingegangen werden; insbesondere sollen folgende Fragen beantwortet werden:

Welche Funktionalitäten hat das Tool? Welche Programmiersprachen werden unterstützt?

Inwiefern lassen sich die Ausgaben des Tools nachvollziehen? Welches Maß an Expertise ist erforderlich?

Welches Vertriebsmodell wird genutzt?

Ist das Tool Open Source?

Wie nutzt das Tool KI? Welche Modelle werden zu welchen Zwecken verwendet?

Bundesamt für Sicherheit in der Informationstechnik 9

Welche Stärken und Schwächen weist das Tool auf?

Wie unterscheidet sich das Tool von anderen Tools derselben Toolklasse?

Welche Schnittstellen zu anderen Tools hat es? Ist es auf bestimmte Dateiformate angewiesen?

Welche Basisfunktionen sollte eine Toolklasse in einem gewissen Anwendungsgebiet (z.B. Schwachstellenidentifikation, Schwachstellenbehebung, automatisiertes Vexing, …) erfüllen?

2. Um die Tools aus der Übersicht vergleichbar zu machen, müssen vom AN nachvollziehbare und aussagekräftige Bewertungskriterien und entsprechende Gewichtungen erarbeitet und mit dem AG abgestimmt werden. Die Bewertungskriterien sollen falls möglich ganze Toolklassen abdecken und vergleichbar machen. Im Anschluss führt der AN eine Multi-Criteria-Analyse (MCA) durch, um die Tools zu vergleichen, Stärken und Schwächen aufzuzeigen, sowie Herausstellungsmerkmale zu benennen. Die Verschriftlichung der MCA kann in tabellarischer Form erfolgen; das genaue Format stimmt der AN im Voraus mit dem AG ab. Das Ergebnis der Analyse muss eine begründete, nachvollziehbare Vorauswahl der vielversprechendsten Ansätze sein (pro Toolklasse max. 3, Abweichungen in Abstimmung zwischen AG und AN möglich). Die Auswahl erfolgt in enger Abstimmung mit dem AG. Die Anzahl der gewählten Tools darf ein kritisches Maß nicht übersteigen, sodass eine Bearbeitung in der vorgesehen Anzahl an Personentagen möglich ist (vgl. Kapitel 3)

3. Auf Grundlage der Vergleiche sind die zuvor ausgewählten Tools im Detail zu untersuchen. Dazu müssen einerseits geeignete und repräsentative Testfälle geschaffen werden und andererseits passende Metriken definiert werden, um die Leistungsfähigkeit in der Praxis bewerten zu können. Auf Basis dieser Testfälle werden die vorausgewählten Tools praktisch untersucht und unter Berücksichtigung der Metriken miteinander verglichen. Dabei muss auf die unterschiedlichen Toolklassen eingegangen werden. Eine separate Betrachtung für die verschiedenen Anwendungsgebiete muss, falls nötig, vorgenommen werden. Im Zuge dieser Auswertung stehen, falls nötig, Gelder für Softwarelizenzen zum Abruf bereit (vgl. Kapitel 3). Geplante Ausgaben des AN werden vorab mit dem AG abgestimmt und erfordern dessen Zustimmung.

4. Unter Berücksichtigung beider Vergleiche, die also einerseits auf der MCA basieren (siehe oben, 2.) und andererseits die praktischen Untersuchungen anhand von Testfällen nutzen (siehe oben, 3.), erfolgt eine Einschätzung, welche der Ansätze am vielversprechendsten erscheinen und im weiteren Verlauf des Projekts mindestens betrachtet werden müssen

Der AN muss die Ergebnisse seiner Untersuchungen aus 1., 2. und 3. in verständlicher Form vollständig und strukturiert in einem zur Veröffentlichung geeigneten, Dokument zusammenfassen, das sich an Fachexperten aus der KI-Forschung und der Wirtschaft richten soll. Das Dokument muss in zwei Versionen, einmal in deutscher und einmal in englischer Sprache erstellt werden. In das Dokument müssen also, wie in den Teilaufgaben bereits beschrieben, sowohl die Übersicht zu bestehenden Ansätzen, als auch die gewichteten Bewertungskriterien und der auf ihnen basierende Vergleich (MCA), eine Beschreibung der Testfälle und Metriken und der auf ihnen basierende Vergleich sowie die begründete Auswahl vielversprechender Ansätze einfließen. Aus Gründen der Produktneutralität müssen die Informationen zu konkreten, bestehenden Softwareprodukten im durch den AN zu erstellenden Dokument von den übrigen Informationen separiert werden, beispielsweise durch Einfügen eines eigenen produktbezogenen Kapitels. Des Weiteren muss auf die Dual-Use-Problematik eingegangen werden, und das Dokument so gestaltet werden, dass eine missbräuchliche Verwendung der Ergebnisse möglichst vermieden wird.

Der Umfang des Berichts muss 30 – 45 mit Inhalt gefüllte Seiten in der Schriftart „BundesSans Regular“ mit Schriftgröße 11 und üblichem Zeilenabstand umfassen; auf die Teilaufgaben 2 und 3 müssen hierbei mindestens die Hälfte der Länge des Dokuments entfallen, sodass sichergestellt ist, dass diese Themen ausreichend beleuchtet wurden. Das Ergebnisdokument ist auf Grundlage des zum Zeitpunkt der Erstellung aktuellen Standes von Wissenschaft und Technik zu erstellen. Die Erarbeitung hat unter Anwendung anerkannter wissenschaftlicher Methoden sowie unter Beachtung der Grundsätze guter wissenschaftlicher Praxis zu erfolgen. Abweichungen von diesen Vorgaben sind nur nach Absprache mit dem AG möglich.

10 Bundesamt für Sicherheit in der Informationstechnik

Jedweder Einsatz von KI zur Erstellung des Dokuments ist nur nach vorheriger Absprache zwischen AN und AG und mit Zustimmung des AG möglich.

Das Ergebnisdokument wird dem AG zum Abschluss des AP durch den AN zusammenfassend in einem virtuellen Termin vorgestellt und durch den AG abgenommen.

Die Ergebnisse von 4. sind nicht Teil der Veröffentlichung, müssen aber dennoch schriftlich dokumentiert und dem AG am Ende des APs in verständlicher Form übermittelt werden. Das genaue Format wird im Rahmen des Auftaktworkshops abgestimmt.

Für AP 2 wird durch den AG eine Obergrenze von 130 PT festgelegt. Die Vorgaben hinsichtlich ggf. anfallender Lizenzkosten sind durch den AN zu beachten (vgl. Kapitel 3.1.2.2). Um den Stand der Arbeiten zu verfolgen und dem AG die Möglichkeit zu geben, inhaltliche Schwerpunkte zu setzen und Feedback zu geben, finden regelmäßig alle zwei Wochen sowie bei Bedarf anlassbezogene Besprechungen über Videokonferenz zwischen AG und AN statt (jeweils max. 2 Stunden). Der AN berichtet hierbei über den aktuellen Stand der Arbeiten und die geplanten inhaltlichen Aktivitäten der nächsten zwei Wochen. Er fertigt zu jeder solchen Besprechung ein kurzes Ergebnisprotokoll an und legt dieses dem AG innerhalb von drei Werktagen nach der jeweiligen Besprechung zur Abnahme vor.

Falls der AG feststellt, dass, auf Basis der Ergebnisse von AP 2 die Projektziele wahrscheinlich nicht oder nur unzureichend erfüllt werden können, hat er die Möglichkeit eine Nachbesserung durch den AN zu fordern oder das Projekt an dieser Stelle vorzeitig zu beenden. Die Wahrnehmung dieser Optionen wird durch den AG sachlich begründet und erfolgt innerhalb von zwei Wochen nach dem Vorstellungstermin für das Ergebnisdokument und dem Vorliegen der schriftlichen Ergebnisse. Um einen solchen Abbruch nach Möglichkeit zu vermeiden, gibt der AG regelmäßiges Feedback.

2.3 Arbeitspaket 3: Erarbeitung von Best Practices zum Einsatz

ausgewählter Tools im SSDLC und Erstellung eines Proof of

Concepts (Best Practices und PoC)

In diesem Arbeitspaket muss der AN basierend auf den bisherigen Untersuchungen Best Practices zum Einsatz der in AP 2 untersuchten Tools herleiten. Die Best Practices sollen den Einsatz der Tools sicher und effizient machen, und auf die größten Probleme der Tools eingehen. Idealerweise sind die Best Practices auf alle Tools einer Toolklasse anwendbar, können falls nötig aber auch spezifischer sein. Einhergehend mit der Erarbeitung dieser Best Practices ist ein PoC zu entwickeln, welcher die Best Practices für die ausgewählten Tools entsprechend umsetzt und aufzeigt, dass der Einsatz unter den Vorgaben der Best Practices möglich und praktikabel ist. Der PoC ist somit als Framework aufzusetzen, das den Best Practices folgt und die gewählten Tools im Rahmen dieser Best Practices nutzbar macht. Die genaue Form des PoC ist im Laufe von AP 2 und 3 mit dem AG abzustimmen, und ist abhängig von den Ergebnissen der Untersuchungen. Dies soll als Grundlage zur Weiterarbeit im Rahmen folgender APs dienen.

Die Best Practices können mitunter auf die korrekte Verwendung der Tools (z.B. Besonderheiten bei der Nutzung) abzielen oder sich auf den Umgang mit ihren Ausgaben (z.B. im Hinblick auf False Positives) beziehen. Sie sind in Form von konkreten, in der Praxis anwendbaren Leitlinien darzustellen, und müssen ausreichend begründet werden. Dabei müssen die entsprechenden Toolklassen berücksichtigt und die Best Practices entsprechend den speziellen Anforderungen angepasst werden.

Der AN muss die Best Practices in einer für Anwender verständlichen und praxisorientierten Form in einem Dokument festhalten. Dieses muss zwischen 5 und 15 mit Inhalt gefüllte Seiten in der Schriftart „BundesSans Regular“ mit Schriftgröße 11 und üblichem Zeilenabstand umfassen. Abweichungen hiervon müssen mit dem AG abgestimmt werden. Das Dokument soll, ggf. gemeinsam mit dem PoC (siehe unten), veröffentlicht werden.

Bundesamt für Sicherheit in der Informationstechnik 11

Für den PoC ist vom AN zunächst ein Anforderungskatalog zu definieren, welcher mit dem AG abgestimmt werden muss. Der Anforderungskatalog ist in Tabellenform zu erstellen und muss sich auf die wesentlichen Punkte beschränken (ca. 1 DIN-A4 Seite). Er soll Missverständnissen in der Erwartungshaltung für beide Seiten vorbeugen und sicherstellen, dass der PoC zur Durchführung weiterer Arbeitsschritte (AP 5, 6, 7) geeignet ist. Erst nach der Freigabe des Anforderungskatalogs kann mit der Implementierung des PoCs begonnen werden.

Die Entwicklung des PoC ist umfassend zu dokumentieren und Entscheidungen schriftlich zu begründen. Bei der Erstellung ist darauf zu achten, dass die notwendigen Voraussetzungen auch im behördlichen Umfeld vorhanden sind (z.B. benötigte Hardware oder Zugang zu Onlinediensten), und die Best Practices sowohl in der Wirtschaft als auch in Behörden umsetzbar sind. Wenn alternative Lösungen möglich sind, sind diese zu erwähnen und theoretisch darzustellen.

Die Ergebnisse dieses AP sollen als Anhang an den Bericht angefügt werden, der in AP 2 erstellt wird. Ob der Anhang Teil der Veröffentlichung wird, wird in Absprache zwischen AN und AG nach Sichtung der Ergebnisse entschieden.

Für AP 3 wird durch den AG eine Obergrenze von 50 PT festgelegt. Um den Stand der Arbeiten zu verfolgen und dem AG die Möglichkeit zu geben, inhaltliche Schwerpunkte zu setzen und Feedback zu geben, finden regelmäßig alle zwei Wochen sowie bei Bedarf anlassbezogene Besprechungen über Videokonferenz zwischen AG und AN statt (jeweils max. 2 Stunden). Der AN berichtet hierbei über den aktuellen Stand der Arbeiten und die geplanten inhaltlichen Aktivitäten der nächsten zwei Wochen. Er fertigt zu jeder solchen Besprechung ein kurzes Ergebnisprotokoll an und legt dieses dem AG innerhalb von drei Werktagen nach der jeweiligen Besprechung zur Abnahme vor.

2.4 Arbeitspaket 4: Zwischenworkshop zur Vorstellung bisheriger

Ergebnisse und Feinkonzept (Zwischenworkshop)

In diesem AP muss der AN dem AG die Ergebnisse aus AP 2 (Studie zu KI im SSDLC) und AP 3 (Best Practices und PoC) umfassend als PowerPoint-Präsentation darstellen. Die bis zu diesem Zeitpunkt durchgeführten Schritte sind zu beschreiben sowie die Resultate und Schlussfolgerungen aufzuzeigen. Auch wird das weitere Vorgehen in Bezug auf AP 5, 6, 7 und 8 abgestimmt und verbleibende offene Fragen zwischen AG und AN diskutiert und verbindlich geklärt.

Die Zwischenpräsentation ist durch den AN in Absprache mit dem AG in einem geeigneten virtuellen Format (z.B. Video- oder Telefonkonferenz) zu organisieren. Die Präsentationsfolien werden dem AG fünf Werktage vor der Präsentation durch den AN zur Verfügung gestellt und dürfen vom AG für weitere interne und externe Präsentationen verwendet werden. Die Präsentation wird auf 4 Stunden begrenzt.

Der AN erstellt ein Besprechungsprotokoll und legt dieses dem AG innerhalb von einer Woche nach der Besprechung vor.

2.5 Arbeitspaket 5 (OPTIONAL): Einordnung und Empfehlungen für

AVA-Bepunktung in den Common Criteria (Aktualisierung

Einordnung CC-Bewertungsmetrik)

(EU)CC-Evaluierungen erfolgen nach dem jeweils aktuellen Stand der Technik und der Wissenschaft. Dementsprechend müssen Prüfstellen, Hersteller und Zertifizierungsstellen technische Entwicklungen generell beim Testen von Softwareprodukten und insbesondere auch bei der Schwachstellenanalyse berücksichtigen. Der Fokus dieses APs liegt im Bereich von Softwareschwachstellen, insbesondere nicht im Bereich der Kryptoseitenkanalanalyse.

12 Bundesamt für Sicherheit in der Informationstechnik

Durch KI-Tools und -Techniken könnten sich insbesondere Angriffe vereinfachen, die entweder neue Angriffspfade ermöglichen oder bisher entweder nur mit großem Zeitaufwand und/oder nur mit umfassenden, technischen Fachkenntnissen (Experten) durchgeführt werden konnten, siehe hierzu CEM:2022, Anhang B 6.2.3. Sofern sich hier neue Möglichkeiten ergeben und/oder sich Aufwände reduzieren, hat dies erhebliche Auswirkungen auf die Sicherheit von IT-Produkten. CEM:20222, Anhang B 6.2.3 unterscheidet hier nach

“The following factors should be considered during analysis of the attack potential required to exploit a vulnerability:

a) Time taken to identify and exploit (Elapsed Time);

b) Specialist technical expertise required (Specialist Expertise); [Welche Fachkenntnisse sind erforderlich um einen Angriff überhaupt durchführen zu können.]

c) Knowledge of the TOE design and operation (Knowledge of the TOE); [Im Softwareumfeld ist häufig davon auszugehen, dass der Code selbst nicht geschützt oder/und frei verfügbar ist.]

d) Window of opportunity; [Zugriffsmöglichkeit auf den Evaluierungsgegenstand respektive das IT-Produkt. Hier ist beispielsweise zu berücksichtigen, wie lange ein Zugriff möglich/notwendig ist, ohne dass ein solcher auffällt und (automatische oder manuelle) Gegenmaßnahmen ergriffen werden.]

e) IT hardware/software or other equipment required for exploitation”

Von besonderem Interesse für AP 5 sind demnach KI-Tools und -Techniken, die ein oder mehrere der o.g. Elemente der Angriffs-Bewertungsmetrik gegenüber klassischen Angriffs- (Brute Force, Injection, Speicherüberläufe etc.) und Analysetechniken (statischer/dynamischer Codeanalyse, Fuzzing etc.) signifikant reduzieren bzw. vereinfachen.

Im Rahmen dieses AP wird untersucht, inwiefern die Schwachstellenbewertungskriterien in der Common Criteria Zertifizierung an die eventuell neuen Gegebenheiten, die durch den (böswilligen) Einsatz von KI in der Schwachstellensuche und -ausnutzung entstehen, angepasst werden müssen. Dabei erfolgt unter Verwendung der Ergebnisse von AP 2 und AP 3 eine Einordnung der in AP 2 und AP 3 identifizierten Fähigkeiten der KI-Tools in die AVA-Bepunktungstabelle entsprechend oben genannter Vorgaben aus der CEM durch den AN in Zusammenarbeit mit dem AG. So ist beispielsweise denkbar, dass mithilfe von KI z.B. generell kürzere ‚windows of opportunity‘ oder geringere ‚Specialist Expertise ‘ nötig sind, um Schwachstellen zu identifizieren und auszunutzen. Der AN muss hierzu die Ergebnisse aus AP 2 und 3 so aufbereiten, dass sie in diesem AP nutzbar sind, mit einem Fokus auf Dual-Use Tools. Insbesondere die Testfälle müssen mit Hinblick auf die Schwachstellenbewertungskriterien ausgewertet und bei Bedarf ergänzt werden. Hierfür sollen auch empirische Untersuchungen durchgeführt werden. Falls nötig, müssen die Ergebnisse aus AP 2 und 3 noch einmal mit Hinblick auf die Anforderungen dieses AP vertieft werden.

Auf Basis der Untersuchungen werden konkrete, schriftliche Empfehlungen und Erläuterungen für die Bepunktung von Schwachstellen anhand der AVA-Bepunktungstabelle, die sich aus dem (böswilligen) Einsatz von KI in der Schwachstellensuche ergeben, erarbeitet. Darin erfolgt insbesondere ein Vergleich zwischen der Bepunktung von Schwachstellen anhand der AVA-Bepunktungstabelle einmal ohne den Einsatz von KI und einmal mit dem Einsatz von KI. Alle Änderungen und Entscheidungen werden dabei schriftlich begründet.

Aufgrund des erforderlichen Expertenwissens im Bereich der CC-Zertifizierung unterstützt und berät der AG den AN bei Bedarf. Grundsätzlich wird jedoch vorausgesetzt, dass sich alle Beteiligten im Vorfeld mit CEM:2022, Anhang B auseinandergesetzt haben.

Für AP 5 wird durch den AG eine Obergrenze von 66 PT festgelegt. Um den Stand der Arbeiten zu verfolgen und dem AG die Möglichkeit zu geben, inhaltliche Schwerpunkte zu setzen und Feedback zu geben, finden regelmäßig alle zwei Wochen sowie bei Bedarf anlassbezogene Besprechungen über Videokonferenz zwischen AG und AN statt (jeweils max. 2 Stunden). Der AN berichtet hierbei über den aktuellen Stand der

2 https://www.commoncriteriaportal.org/cc/index.cfm

Bundesamt für Sicherheit in der Informationstechnik 13

Arbeiten und die geplanten inhaltlichen Aktivitäten der nächsten zwei Wochen. Er fertigt zu jeder Besprechung ein Ergebnisprotokoll an und legt dieses dem AG innerhalb von drei Werktagen nach der jeweiligen Besprechung zur Abnahme vor.

2.6 Arbeitspaket 6 (OPTIONAL): Erstellung einer Guideline für den

Einsatz von KI-Tools mit Dual-Use in Prüfstellen und ggf. bei

Herstellern (Guideline: KI-Tools in der Evaluierung in

Prüfstellen)

(EU)CC-Evaluierungen erfolgen nach dem jeweils aktuellen Stand der Technik und der Wissenschaft. Dementsprechend müssen Prüfstellen, Hersteller und Zertifizierungsstellen technische Entwicklungen generell beim Testen von Softwareprodukten und insbesondere auch bei der Schwachstellenanalyse berücksichtigen. Dieses AP dient dazu, dass sich die genannten Gruppen frühzeitig auf diesbezügliche technische Entwicklungen im Bereich KI vorbereiten und, sofern vorhanden, entsprechende Tools nutzen können. Der Fokus dieses APs liegt im Bereich von Softwareschwachstellen, insbesondere nicht im Bereich der Kryptoseitenkanalanalyse.

Im Rahmen der Common Criteria Zertifizierung werden die Prüfungen von durch das BSI anerkannten Prüfstellen durchgeführt. Werden im Rahmen von AP 5 die Empfehlungen für die AVA-Bepunktung angepasst, so müssen diese Prüfstellen und ggf. die Hersteller in die Lage versetzt werden, diese Empfehlungen umzusetzen. Der Einsatz der KI-Tools, welche die Empfehlungen aus AP 5 begründen, ist hierbei wichtig.

In diesem AP ist unter Berücksichtigung des aktuellen Forschungsstands eine Guideline zu erstellen, die den Einsatz von KI-basierten Tools in den Prüfstellen vorbereitet und als Zeithorizont insbesondere die nächsten 2 bis 3 Jahre abdeckt. Der AN muss sich dementsprechend intensiv mit kürzlichen, aktuellen sowie erwartbaren Entwicklungen im Kontext des Testens von Softwareprodukten und der Schwachstellenanalyse mittels KI auseinandersetzen. Die Guideline sollte auch für Hersteller von IT-Sicherheitssoftware verständlich sein, damit diese die entsprechenden Tests und Analysen grundsätzlich nachvollziehen können. Dabei ist mindestens auf folgende Punkte im Detail einzugehen:

Die Ergebnisse aus AP 5 müssen Teil der Guideline sein.

Welche Toolklassen sind grundsätzlich relevant?

Welche KI-Tools und -Techniken sind oder könnten zukünftig absehbar geeignet (sein), um in Prüfstellen genutzt zu werden?

Welche KI-Tools und -Techniken sollten Prüfstellen und Hersteller „im Auge behalten“, um nicht absehbar von KI-Entwicklungen im Sinne dieses AP überrascht zu werden?

Welche Kosten und Voraussetzungen sind mit der Einführung entsprechender Tools verbunden?

Was ist bei der Nutzung der KI-Tools und -Techniken zu beachten?

Für welche Schwachstellenkategorien (z. B. OWASP) ist das jeweilige Tool bzw. die jeweilige Technik geeignet?

Hinweis: Hier kann es Überschneidungen zu den Ergebnissen von AP 7 geben, insb. in Hinsicht auf Anwendung von KI-Tools in der sicheren Softwareentwicklung. Ein Abgleich muss hier stattfinden.

Das Vorgehen muss dabei stets dokumentiert werden, und Entscheidungen schriftlich begründet werden. Für AP 6 wird durch den AG eine Obergrenze von 60 PT festgelegt. Um den Stand der Arbeiten zu verfolgen und dem AG die Möglichkeit zu geben, inhaltliche Schwerpunkte zu setzen und Feedback zu geben, finden regelmäßig alle zwei Wochen sowie bei Bedarf anlassbezogene Besprechungen über Videokonferenz

14 Bundesamt für Sicherheit in der Informationstechnik

zwischen AG und AN statt (jeweils max. 2 Stunden). Der AN berichtet hierbei über den aktuellen Stand der Arbeiten und die geplanten inhaltlichen Aktivitäten der nächsten zwei Wochen. Er fertigt zu jeder Besprechung ein kurzes Ergebnisprotokoll an und legt dieses dem AG innerhalb von drei Werktagen nach der jeweiligen Besprechung zur Abnahme vor.

2.7 Arbeitspaket 7 (OPTIONAL): Erstellung einer

Referenzarchitektur für die Integration von KI-Tools des SSDLC

in Open CoDE (Referenzarchitektur KI-Tools im SSDLC in Open

CoDE)

Open CoDE3 ist die gemeinsame Plattform der öffentlichen Verwaltung zum Austausch von Open Source Software (https://opencode.de/de). Projekte auf dieser Plattform abzusichern führt dementsprechend zu einer Erhöhung der Cybersicherheit in der Bundesverwaltung insgesamt. OpenCoDE stellt bereits diverse Tools zur Verbesserung der Sicherheit des hinterlegten Codes zur Verfügung. Dieser Katalog soll durch die Einführung von KI-Tools erweitert werden, die den SSDLC unterstützen. Durch den konsequenten Einsatz von Open Source besteht die Chance, mit den eingesetzten Mitteln eine große Wirkung zu erzielen und den State of the Art voranzutreiben. Bei den eingesetzten KI-Modellen ist aus Gründen der digitalen Souveränität der Einsatz von Open Weight Modellen wünschenswert, auch wenn bei der Erstellung von Open Source Software die Datensouveränität nicht unbedingt im Fokus steht. Auch das Finetuning von Open Weight Modellen für optimierte Ergebnisse beim gewünschten Einsatzzweck sollte Berücksichtigung finden.

Dafür muss in diesem AP eine Referenzarchitektur erstellt werden, die die Integration der KI-Tools im SSDLC in OpenCode darstellt. Dies umfasst mindestens:

Auflistung und Abwägung der Vor-und Nachteile verschiedener Tools, mit Bezug zu den speziellen Gegebenheiten in OpenCoDE

Vorauswahl geeigneter Tools für den Einsatz in OpenCoDE mit Begründung

Erstellung mindestens einer Referenzarchitektur, die die mögliche Integration der Tools in OpenCoDE darstellt

Möglichst genaue und fundierte Schätzung der anfallenden einmaligen und wiederkehrenden Kosten in Anschaffung und Betrieb. Dies beinhaltet auch die Schaffung der nötigen technischen Rahmenbedingungen.

Für OpenCoDE sind hierbei primär Tools von Interesse, die im Secure Software Development Life Cycle zu späteren Phasen, i.e. Testing und Deployment, eingesetzt werden. Darunter fallen beispielsweise:

Beim Fuzzing kann KI die Logik der Anwendung berücksichtigen und dadurch besonders effektiv Edge Cases finden. Diese ermittelten Edge Cases finden auch bei der Testfallgenerierung Verwendung.

Wünschenswert ist eine auf Grundlage von Tickets automatisierte Generierung von Testfällen. Diese stellen dann einen Teil des Fixes dar und sorgen für Qualität durch eine Ergänzung der Testabdeckung und schützen vor Regressionen.

In der Deployment-Phase erkennt KI auffällige Telemetriedaten und kann darauf basierend Rollbacks auslösen, entweder halbautomatisch mit menschlicher Bestätigung oder vollautomatisch.

Automatische Vulnerability Triage: Hierbei werden Ergebnisse aus statischen und dynamischen Analysen korreliert und mit einer Reachability-Analysis verknüpft, um die Relevanz von gemeldeten Schwachstellen zu bewerten. Auch automatisches VEXing ist vorstellbar.

3 https://opencode.de/de

Bundesamt für Sicherheit in der Informationstechnik 15

Entdeckt die KI eine neue Schwachstelle in einer Bibliothek, scannt sie proaktiv alle Produktionsumgebungen, ermittelt das Risiko und erstellt einen virtuellen Patch entweder in der Web Application Firewall oder in einem Sidecar-Proxy-Container (Stichwort Self-healing Architecture).

KI kann schließlich auch Natural Language Policy Enforcement ermöglichen, also die Durchsetzung von Sicherheitsrichtlinien durch Anweisungen in natürlicher Sprache.

Auf Grundlage der Referenzarchitektur erstellt ZenDiS eine Roadmap. Dies ist bei der Bearbeitung dieses AP in allen Schritten zu beachten.

Hinweis: Hier kann es Überschneidungen zu den Ergebnissen von AP 6 geben, insb. in Hinsicht auf Anwendung von KI-Tools in der sicheren Softwareentwicklung. Ein Abgleich muss hier stattfinden.

Die Referenzarchitektur ist schriftlich auszuarbeiten, zu begründen und zusammen mit den Erläuterungen bezüglich geeigneter Tools auf mindestens 5 mit Inhalt gefüllte Seiten in der Schriftart „BundesSans Regular“ mit Schriftgröße 11 und üblichem Zeilenabstand festzuhalten.

Für AP 7 wird durch den AG eine Obergrenze von 50 PT festgelegt. Um den Stand der Arbeiten zu verfolgen und dem AG die Möglichkeit zu geben, inhaltliche Schwerpunkte zu setzen und Feedback zu geben, finden regelmäßig alle zwei Wochen sowie bei Bedarf anlassbezogene Besprechungen über Videokonferenz zwischen AG und AN statt (jeweils max. 2 Stunden). Der AN berichtet hierbei über den aktuellen Stand der Arbeiten und die geplanten inhaltlichen Aktivitäten der nächsten zwei Wochen. Er fertigt zu jeder solchen Besprechung ein kurzes Ergebnisprotokoll an und legt dieses dem AG innerhalb von drei Werktagen nach der jeweiligen Besprechung zur Abnahme vor.

2.8 Arbeitspaket 8 (OPTIONAL): Abschlusspräsentation der

Projektergebnisse und Abschlussbericht (Abschlussworkshop)

Die Projektergebnisse werden im Rahmen einer (maximal) halbtägigen Abschlussveranstaltung vom AN vor Fachpublikum (u.a. BSI-Mitarbeitende) präsentiert. Die Veranstaltung ist inhaltlich und organisatorisch grundsätzlich vom AN zu planen. Die Besprechung findet im BSI als virtuelle Besprechung mit Einwahlmöglichkeit für Mitarbeitende des BSI statt. Die Details der Durchführung der Veranstaltung werden im Vorfeld vom BSI festgelegt bzw. zwischen dem BSI und dem AN abgestimmt. Bei der Präsentation werden die wesentlichen Erkenntnisse des Projektes vorgestellt. Dies schließt u. a. folgende Punkte ein:

Aus AP 2 werden die untersuchten KI-Tools im SSDLC zusammenfassend präsentiert und wesentliche Ergebnisse der Studie vorgestellt.

Die in AP 3 erarbeiteten Best Practices und der erstellte PoC wird kurz vorgestellt.

Wurden optionale APs bearbeitet, sind die jeweiligen Ergebnisse ausführlich zu präsentieren:

Zu AP 5 sind die Änderungen in der Common Criteria Bewertungsmetrik im Bereich AVA o vorzustellen, zusammen mit den Gründen für die jeweiligen Anpassungen.

Zu AP 6 ist die Guideline zu präsentieren, die aufzeigt, wie KI-Tools zur Schwachstellenanalyse in o Prüfstellen und ggf. bei Herstellern eingesetzt werden können und welche Tools wofür geeignet sind.

Zu AP 7 ist die Referenzarchitektur vorzustellen und zu erläutern, wieso diese Architektur gewählt o wurde und welche Tools geeignet sind.

Etwaige offene Fragen und mögliche Weiterentwicklungen/nächste Schritte sind vom AN im Anschluss zu benennen.

Die Präsentationsunterlagen (Foliensatz in MS PowerPoint) stellt der AN dem BSI mindestens zehn Werktage vor der Präsentation zur Freigabe zur Verfügung. Von Seiten des BSI können weitere Teilnehmer dazu eingeladen werden. Die teilnehmenden Personen des AN müssen in der Lage sein, Detailfragen zu den

16 Bundesamt für Sicherheit in der Informationstechnik

Inhalten von anwesenden Experten beantworten zu können. Die Anzahl der teilnehmenden Personen seitens des AN ist auf maximal fünf Personen zu beschränken. Die Videokonferenz ist vom AN zu organisieren.

Zudem erstellt der AN einen Abschlussbericht, der ebenfalls auf die o.g. Punkte zusammenfassend eingeht. Dieser muss, etwaige Anhänge ausgerechnet, etwa fünf mit Inhalt gefüllte Seiten in der Schriftart „BundesSans Regular“ mit Schriftgröße 11 und üblichem Zeilenabstand umfassen. Abweichungen hiervon müssen mit dem AG abgestimmt werden.

Bundesamt für Sicherheit in der Informationstechnik 17

3 Zahlungs- und Meilensteinplan, Projektplan und

Vergütung

Die nachfolgenden Kapitel geben einen Überblick über die Vergütung und den zeitlichen Projektverlauf.

3.1 Vergütung

Die Vergütung erfolgt abhängig von den einzelnen Arbeitspaketen / der Art der Leistung entweder als Festpreis oder nach Aufwand bis zu einer maximalen Obergrenze (siehe die verbindlichen Vorgaben in Kapitel 3.2, Tabelle 1, Spalte „Art der Vergütung“).

3.1.1 Vergütung von AP nach Festpreis

Die Vergütungen der Arbeitspakete 1 und 4 sowie des optionalen Arbeitspakets 8 erfolgen per Festpreis.

3.1.2 Vergütung von AP nach Aufwand

Die Arbeitspakete 2 und 3 sowie der optionalen Arbeitspakete 5, 6 und 7 werden nach Aufwand bis zu einer maximalen Obergrenze vergütet. Hierzu sind die tatsächlich angefallenen Aufwände bei Rechnungsstellung zu belegen. Angefallene Aufwände, die nicht zuvor mit dem Auftraggeber abgestimmt wurden, können nicht vergütet werden.

3.1.2.1 Personalkosten

Der Auftraggeber legt für die Arbeitspakete 2 und 3 sowie der optionalen Arbeitspakete 5, 6 und 7 ein jeweiliges Abrufkontingent in Form von Personentagen fest:

• AP 2: 130 Personentage • AP 3: 50 Personentage • Opt. AP 5: 66 Personentage • Opt. AP 6: 60 Personentage • Opt. AP 7: 50 Personentage

Die maximale Obergrenze ergibt sich bei diesen Arbeitspaketen somit aus der vorgegebenen Kontingentgröße und den im Angebot anzugebenden Tagessätzen (siehe Kapitel 6.2.1.4, Zuschlagskriterium 2.3 „Kalkulation der maximalen Obergrenzen“).

Gemeinkosten, Reisekosten sowie sonstige Kosten werden, sofern nicht in Kapitel 3.1.2.2 aufgeführt, nicht gesondert vergütet und müssen daher bereits in den veranschlagten Tagessätzen enthalten sein.

Die angegebenen Tagessätze basieren auf acht Zeitstunden.

Die angefallenen personellen Aufwände sind viertelstundengenau in Rechnung zu stellen und mittels eines Leistungsnachweises (Muster siehe Kapitel D) zu belegen. Der Leistungsnachweis enthält mindestens Angaben zum Leistungsdatum, zu den jeweils eingesetzten Mitarbeitenden, zum zugehörigen Arbeitspaket und zu den jeweils erbrachten Zeiten sowie eine Kurzbeschreibung der jeweils erbrachten Tätigkeit. Die Tätigkeiten der eingesetzten Personen müssen dabei einzeln und personenbezogen erfasst werden.

Bei entsprechendem Nachweis können pro Person und pro Kalendertag bis zu 10 Stunden abgerechnet werden.

Im Laufe des Projektes können in Abstimmung zwischen AN und AG bei Bedarf Personentage auftragswertneutral zwischen den einzelnen (beauftragten) AP verschoben werden.

18 Bundesamt für Sicherheit in der Informationstechnik

Abrufe aus diesem Kontingent erfolgen durch den AG in Textform. Der AN erstellt für den jeweiligen Abruf eine Kalkulation der Personentage. Erst nach Freigabe dieser Kalkulation durch den AG gilt der Abruf als getätigt. Leistungen, die außerhalb des Abrufs geleistet werden, werden nicht vergütet. Sollte das Abrufziel ohne Erfüllung zusätzlicher Leistungen/Personentage nicht erreicht werden können, ist dies unverzüglich nach Kenntnisnahme dem AG zu kommunizieren. Nach Prüfung durch den AG erfolgt ggf. eine Aufstockung der für den betroffenen Abruf zur Verfügung stehenden Personentage. Sollte im Rahmen eines Abrufs der tatsächliche Aufwand die vereinbarte Anzahl von Personentagen unterschreiten, werden die freien Ressourcen wieder dem verbleibenden Kontingent zugerechnet.

3.1.2.2 Lizenzkosten

Für die in AP 2 anfallenden Lizenzkosten legt der AG eine maximale Obergrenze von insgesamt 25.000 € (zzgl. USt) fest. Die Beschaffung der notwendigen Lizenzen erfolgt durch den AN.

Die tatsächlich angefallenen Lizenzkosten sind bei Rechnungsstellung durch Vorlage von Scans/digitalen Kopien der Originalrechnungen zu belegen. Es können nur die in den Originalrechnungen aufgeführten Nettobeträge zzgl. der für die Hauptleistung dieses Auftrages geltenden Umsatzsteuer geltend gemacht werden.

Es ist durch den AN mindestens eine Internetrecherche bzw. ein formloser Preisvergleich durchzuführen. Die Beschaffung erfolgt durch den AN beim Anbieter mit dem wirtschaftlichsten Angebot. Die Einhaltung der Regelungen des Kapitels 3.1.2.2 dieser Leistungsbeschreibung kann durch den AG geprüft werden und ist auf Anforderung vom AN nachzuweisen. Der AN hat daher jeden Beschaffungsvorgang sorgfältig zu dokumentieren und eine sparsame und wirtschaftliche Mittelverwendung nachzuweisen. Handelt der AN ohne ordnungsgemäße Freigabe, sind die Kosten der Beschaffung vom AN selbst zu tragen. Der AN muss Rabatte, Skonti oder sonstige Vergünstigungen, die ihm von Dritten gewährt werden, in Anspruch nehmen und in vollem Umfang an den AG weiterreichen.

• Beschaffung im Namen und auf Rechnung des AN:

Unterliegt das zu beschaffende Testprodukt mindestens dem gleichen Umsatzsteuersatz wie die vom AN im Rahmen dieses Projektes zu erbringende Hauptleistung, so beschafft der AN das Testprodukt direkt im Namen und auf Rechnung des AN.

• Beschaffung im Namen und auf Rechnung des AG (BSI):

Unterliegt das zu beschaffende Testprodukt einem günstigeren Umsatzsteuersatz (z. B. 7 %) o als die vom AN im Rahmen dieses Projektes zu erbringende Hauptleistung (z. B. 19 %), so beschafft der AN das Testprodukt direkt im Namen und auf Rechnung des AG (mit Lieferanschrift des AN). Auf der Rechnung des Herstellers / des Lieferanten ist der AG (BSI) zwingend als Rechnungsempfänger zu nennen. Die Zahlung der Rechnungsbeträge an die Hersteller / die Lieferanten erfolgt durch den AG. Es ist außer in mit dem AG abgestimmten Ausnahmefällen ein Zahlungsziel von 30 Tagen zu vereinbaren. Der AG hält für die Begleichung dieser Rechnungen ein ausreichendes Budget bereit.

Der AG ist unverzüglich über den Eingang der Ware und die Mangelfreiheit bzw. die o bestehenden Mängel zu informieren.

• Für alle Beschaffungen ist eine Freigabe durch den AG erforderlich.

Die beschafften Lizenzen sind dem AG nach Abschluss der entsprechenden Tests, spätestens jedoch zum Projektende dem AG zu übergeben bzw. zu übereignen oder den Restwert an den Auftraggeber auszukehren.

Sämtliche Lizenzen sind grundsätzlich so zu wählen, dass dem AG nach Projektabschluss keine weiteren Lizenzkosten entstehen. Abweichungen hiervon sind nur nach Zustimmung des AG möglich.

Bundesamt für Sicherheit in der Informationstechnik 19

3.2 Projektverlauf, Zahlungs- und Meilensteinplan

Die Projektlaufzeit beginnt mit dem Datum der Auftragserteilung (Projektstart) und endet 6 Kalenderwochen nach der durch den AN im Angebot festgelegten Dauer für die Auftragsdurchführung. Für die Fertigstellung des Projektes wird vom AG dabei ein Zeitrahmen von maximal 8 Kalendermonaten verbindlich vorgegeben, inklusive der Zeit, die ggf. für die Beauftragung der optionalen Arbeitspakete durch den AG benötigt wird. Bei einer Auftragsänderung verschiebt sich das Projektende entsprechend der Änderung. Bei erforderlichen Nachbesserungen endet die Projektlaufzeit erst mit vollständiger Abnahme der Gesamtleistung.

Kam es bei der Auftragserteilung zu zeitlichen Verschiebungen (vgl. Kapitel 6.2.1.4, Zuschlagskriterium 2.5 „Zahlungs- und Meilensteinplan“), so werden die daraus ggf. resultierenden Terminverschiebungen verbindlich zwischen AN und AG abgestimmt. Die Terminverschiebungen müssen sich innerhalb der Projektlaufzeit befinden. Der aktualisierte Meilensteinplan ist vom AN mit dem Besprechungsprotokoll, jedoch spätestens 6 Kalenderwochen nach der Auftragserteilung schriftlich oder in Textform vorzulegen. Nach Freigabe durch die BSI-Projektleitung (in Textform) wird der aktualisierte Meilensteinplan Vertragsbestandteil. Liegt innerhalb von 6 Kalenderwochen kein abgestimmter geänderter Meilensteinplan vor, so bleibt der mit dem Angebot vorgelegte Meilensteinplan gültig.

Die Auftaktbesprechung ist seitens des AN in Abstimmung mit dem AG spätestens vier Kalenderwochen nach Auftragserteilung anzusetzen.

AP 2 und 3 müssen spätestens 4 Monate nach dem offiziellen Projektstart abgeschlossen werden.

Manche Arbeitspakete bauen aufeinander auf und sind daher zwingend nacheinander zu bearbeiten. Bei den optionalen Arbeitspaketen 5, 6 und 7 ist eine (teilweise) parallele Bearbeitung möglich. Sie sind jedoch nach den Arbeitspaketen 1, 2, 3 und 4 zu beginnen und hängen von den dort durchgeführten Arbeiten ab (siehe auch Kapitel 1.4). Ein früherer Start ist in Absprache mit dem AG möglich, wenn entsprechende Ergebnisse aus den AP 2 und 3 vorliegen. Um einen planmäßigen Start der optionalen Arbeitspakete zu ermöglichen, ist vorgesehen, dass die weitere Beauftragung mindestens zwei Wochen vor dem geplanten Start des jeweiligen Arbeitspakets durch die Projektleitung im BSI in die Wege geleitet wird.

Jedes der Arbeitspakete wird einem Meilenstein zugeordnet. Ein Meilenstein gilt als erreicht, sobald die ihm zugeordneten Arbeitspakete erbracht und vom AG abgenommen wurden. Grundsätzlich können nur vollständig erbrachte Arbeitspakete abgenommen werden. Eine Rechnungslegung ist erst nach Erreichen eines Meilensteins zulässig (siehe auch Kapitel 4.11). Der Rechnung sind die Abnahmeprotokolle für die Arbeitspakete bzw. das Abnahmeprotokoll für den Meilenstein sowie die erforderlichen Belege (siehe Kapitel 3.1.2.1 und Kapitel 3.1.2.2) beizufügen.

20 Bundesamt für Sicherheit in der Informationstechnik

Tabelle 1 - Zahlungs- und Meilensteinplan

Der hier dargestellte und nicht vollständig befüllte Zahlungs- und Meilensteinplan dient als Übersicht über den derzeit vom AG als sinnvoll erachteten Projektverlauf. Bei den Angaben in der Spalte „Termin nach Projektstart (Beginn, Ende)“ handelt es sich um unverbindliche Schätzwerte des AG. Im Rahmen des Angebotes ist ein konkreter und verbindlicher Zahlungs- und Meilensteinplan in der obenstehenden Darstellungsform vorzulegen (siehe Kapitel 6.2.1.4, Zuschlagskriterium 2.5 „Zahlungs- und Meilensteinplan“). Dabei sind die Spalten „Beginn“ und „Ende“ zu befüllen. Die verbindlichen Vorgaben aus Kapitel 3.1 sind zwingend zu beachten.

Bundesamt für Sicherheit in der Informationstechnik 21

4 Rahmen- und Ausführungsbedingungen

In diesem Kapitel sind die Rahmen- und Ausführungsbedingungen für die Projektdurchführung festgelegt. Deren Einhaltung wird durch Abgabe eines Angebotes automatisch von den Bietern bestätigt (siehe Angebotsformular, Ziffer 3 „Erklärungen des Bieters“).

4.1 Personal des Auftragnehmers

Für die Erbringung der Leistung sollten vom AN mindestens 4 (AP, 2, 3) bzw. 2 (restliche APs) Personen eingesetzt werden (inkl. Projektleitung).

4.1.1 Direktionsrecht und Disziplinargewalt

AG und AN werden durch organisatorische Maßnahmen gewährleisten, dass die jeweils von Ihnen abgestellten Personen für die Leistungserbringung ausschließlich dem Direktionsrecht und der Disziplinargewalt des jeweiligen Arbeitsgebers unterstehen. Weisungen erfolgen ausschließlich im Rahmen der vereinbarten Aufgabenverteilung.

4.1.2 Qualifikationen, Erfahrungen und sonstige Anforderungen

Die zur Erbringung der Leistungen eingesetzten Personen müssen vereinbarungsgemäß, unabhängig davon jedoch mindestens dem Vertragszweck und der Aufgabenstellung entsprechend, qualifiziert sein. Unabhängig davon wird der AN gewährleisten, dass die für die Leistungserbringung vorgesehenen Personen über die Qualifikation verfügen, die mindestens seinen diesbezüglichen Angaben sowie den Anforderungen des AG im Vergabeverfahren entspricht.

Für die einzelnen vorgesehenen Rollen gelten die nachfolgend aufgelisteten Mindestanforderungen. Deren Erfüllung ist im Angebot mit geeigneten Referenzen zu belegen (siehe Kapitel 6.2.1.4).

a) Projektleitung (PL):

Erfolgreiche Leitung von mindestens einem Forschungsprojekt im KI-Bereich, welches mit der hier zu vergebenden Leistung vergleichbar ist (hinsichtlich Dauer, Umfang und Inhalt) oder darüber hinaus geht, nachzuweisen durch mindestens eine Referenz

Mindestens Diplom-/ Masterabschluss im mathematisch-/ informatisch- / natur-/ oder ingenieurwissenschaftlichen Bereich

b) Stellvertretende Projektleitung (PL):

Erfolgreiche Leitung oder stellvertretende Leitung von mindestens einem Forschungsprojekt, welches mit der hier zu vergebenden Leistung vergleichbar ist (hinsichtlich Dauer, Umfang und Inhalt) oder darüber hinaus geht, nachzuweisen durch mindestens eine Referenz

Mindestens Diplom-/ Masterabschluss im mathematisch-/ informatisch- / natur-/ oder ingenieurwissenschaftlichen Bereich

c) Teamqualifikation

Die folgenden Mindestanforderungen müssen jeweils von mindestens einer und können von verschiedenen Personen des Projektteams abgedeckt werden:

Erfahrung in mind. zwei Forschungsprojekten mit Schwerpunkt KI

Fachexpertise im Bereich des SSDLC

Erfahrung in der Entwicklung, Implementierung und Nutzung von KI-Tools

22 Bundesamt für Sicherheit in der Informationstechnik

Relevante Programmierkenntnisse und Erfahrung mit relevanten Frameworks

Die Fähigkeit, technische und wissenschaftliche Sachverhalte verständlich, nachvollziehbar sowie sprachlich einwandfrei aufzubereiten und zusammenhängend darzustellen; mindestens ein Mitarbeiter muss Erfahrung in der Verfassung wissenschaftlicher Dokumente besitzen, nachzuweisen durch mind. drei Publikationen im KI-Bereich oder im Bereich der Cybersicherheit bei einschlägigen Konferenzen und/oder Fachzeitschriften, idealerweise davon mind. eine bei einer Tier-1-Konferenz

Generelles Wissen im Bereich der Produktevaluierung

d) alle Personen des Projektteams

Mindestens Bachelorabschluss (oder ein vergleichbarer Abschluss) im mathematisch-/ informatisch- / natur-/ oder ingenieurwissenschaftlichen Bereich. Alternativ ist eine einschlägige Berufserfahrung von mindestens 5 Jahren in einem gleichwertigen Arbeitsgebiet nachzuweisen

4.1.3 Personaleinsatz und -austausch

Der AN hat zwingend mindestens das Personal einzusetzen, das er im Rahmen seines Angebots (Anlage: „Angebotsangaben gemäß den Besonderen Bewerbungsbedingungen“) als konkret einzusetzendes Personal mit Qualifikationsprofilen angeboten hat. Unabhängig davon hat er nur solches Personal einzusetzen, das für die jeweils zu erbringende Leistung hinreichend qualifiziert ist. Für jede Person, die eingesetzt wird, hat der AN spätestens eine Woche vor dem geplanten Einsatz ein Qualifikationsprofil einzureichen, es sei denn, es liegt die jeweilige Person betreffend ein solches Qualifikationsprofil beim AG bereits vor. Ein Austausch von Personal ist nur nach vorheriger Zustimmung durch den AG zulässig.

Der AG wird seine Zustimmung im Fall eines berechtigten Grundes und wenn ein gleich- oder höherwertiger Ersatz angeboten wird erteilen. Ein berechtigter Grund liegt beispielsweise vor, wenn der Austausch aufgrund Krankheit oder Ausscheiden der betreffenden Person aus dem Unternehmen oder vergleichbarer Umstände, bedingt ist. Die Umstände sind vom AN darzulegen und plausibel zu machen. Kein berechtigter Grund ist der Einsatz der betreffenden Person in einem anderen Projekt oder ein Umzug des Standorts des Unternehmens. Die Gleichwertigkeit des Ersatzes orientiert sich anhand des für die auszutauschende Person vormals eingereichten Qualifikationsprofils, soweit ein solches vorliegt, andernfalls nach billigem Ermessen.

Eine höhere Qualifikation der Ersatzperson begründet keinen Anspruch auf Erhöhung der Vergütung.

Die durch den Austausch und die Einarbeitung der Ersatzperson entstehenden Kosten gehen zu Lasten des AN.

Das eingetauschte Personal ist unverzüglich auf Kosten des AN vollumfänglich einzuarbeiten. Soweit möglich arbeitet die ausscheidende Person die Ersatzperson ein.

4.2 Projektorganisation und Erreichbarkeit

Durch den AN ist eine qualifizierte Person als Projektleitung zur Verfügung zu stellen, die sich mit der Projektleitung des AG abstimmt und die durchzuführenden Arbeiten auf Seiten des AN koordiniert.

Die Projektleitung muss während der üblichen Arbeitszeiten (Montag bis Freitag, jeweils mindestens von 9:30 bis 15:30 Uhr) regelmäßig telefonisch oder per E-Mail erreichbar sein. Sollte die Projektleitung verhindert sein, muss jeweils eine Vertreterin oder ein Vertreter benannt werden.

Seitens des AG wird das Projekt von Referat T25 geleitet. Ansprechpartner/-innen werden bei Erteilung des Zuschlags mitgeteilt.

Bundesamt für Sicherheit in der Informationstechnik 23

4.3 Projektsprache

Die Projektsprache ist grundsätzlich Deutsch. Abweichungen sind in der folgenden Tabelle aufgeführt und können in Abstimmung zwischen AG und AN erweitert oder gestrichen werden:

4.4 Besprechungen

Die Auftaktbesprechung (AP 1), die Präsentation der Zwischenergebnisse (AP 4) sowie die Abschlussbesprechung (AP 8) finden virtuell statt.

Zudem sind im Rahmen der Arbeitspakete AP 2, AP 3, AP 5, AP 6 und AP 7 regelmäßige, virtuelle (Video- oder Telefonkonferenz) Arbeitstreffen, etwa alle zwei Wochen, einzuplanen, um das weitere Vorgehen abzustimmen und dem AG die Möglichkeit zu geben, inhaltliche Schwerpunkte zu setzen und Feedback zu geben. Der AN berichtet in diesen regelmäßigen Besprechungen über den aktuellen Stand der Arbeiten und die geplanten inhaltlichen Aktivitäten der nächsten zwei Wochen. Darüber hinaus stattfindende Meetings zur Diskussion von Zwischenergebnissen finden nach Absprache ebenfalls virtuell statt. Der AN stellt, sofern nicht anders zwischen AG und AN vereinbart, die Plattform für die anfallenden virtuellen Treffen (Videokonferenzen).

Zu jedem Arbeitstreffen ist ein schriftliches Protokoll durch den AN anzufertigen, in dem die Beschlüsse und Ergebnisse festgehalten werden. Das Protokoll ist dem AG, sofern nicht anders vereinbart, spätestens drei Arbeitstage nach Stattfinden des jeweiligen Arbeitstreffens zur Freigabe vorzulegen.

Struktur und Format der Besprechungsprotokolle werden im Rahmen der Auftaktbesprechung festgelegt. Abweichungen von den vereinbarten Regelungen zu den Besprechungen und der entsprechenden Protokollierung bedürfen der Zustimmung des AG.

4.5 Berichtswesen

Im Rahmen des Berichtwesens erhält der AG vom AN alle 14 Tage einen tabellarischen, fortlaufend zu erweiternden und aussagekräftigen Kurzbericht per E-Mail über den Verlauf. Mögliche Probleme im Projektverlauf sind sofort anzuzeigen und dem AG gegenüber besonders hervorzuheben. Die vertraglichen Regelungen in Ziffer 9 des Projektvertrages bleiben unberührt.

Struktur und Format der regelmäßigen Berichte werden im Rahmen der Auftaktbesprechung festgelegt.

Abweichungen vom vereinbarten Berichtswesen sind möglich, bedürfen jedoch der Zustimmung des BSI.

4.6 Formale Anforderungen an Projektdokumente

Der AN übermittelt die Projektdokumente (Projektergebnisse, Besprechungsprotokolle, Berichte) in elektronischer Form entweder im Open XML-Dateiformat (DOCX) oder im Portable Document-Format (PDF) an den AG. Wurde sich auf die Erstellung von Microsoft Word-Dokumenten geeinigt, so ist in diesen grundsätzlich auf die Referenzierung von OLE-Objekten (Object Linking and Embedding) zu verzichten. Ausnahmen von diesen Dateiformaten und Regelungen sind erst nach Absprache mit dem AG möglich. Die Ergebnisdokumente aus AP 2, AP 3, AP 5 und AP 6 sind dem AG sowohl in editierbarer Form als auch als PDF- Datei vorzulegen.

Alle Projektdokumente sind übersichtlich strukturiert und enthalten (wenn sinnvoll) ein Inhaltsverzeichnis, eine Zusammenfassung, eine Dokumenten-Version, eine Änderungshistorie mit Erstellungs- und

24 Bundesamt für Sicherheit in der Informationstechnik

Bearbeitungs-Datum sowie der Liste der Autoren, so dass Erstellung und Änderung des jeweiligen Dokuments nachvollziehbar sind. Sämtliche Dateien – unabhängig vom Dateityp, d.h. sowohl Open XML, Portable Document, als auch Bilddatei etc.– müssen vom AN von Metadaten bereinigt werden. Es dürfen in den Metadaten weder personenbezogene Daten enthalten sein, noch Informationen zur eingesetzten Software.

Die sprachliche Qualität ist von großer Bedeutung. Im Durchschnitt sind pro Textseite maximal vier sprachliche Fehler, das heißt grammatikalische Fehler oder Rechtschreibfehler, zulässig.

Zudem ist darauf zu achten, dass mindestens Ergebnisdokumente, welche (möglicherweise) zur Veröffentlichung vorgesehen sind, in geschlechtergerechter Sprache zu erstellen sind. Dabei sind mindestens die Anforderungen für Gesetzestexte (siehe Handbuch der Rechtsförmlichkeit des BMJ: http://hdr.bmj.de/page_b.1.html#an_110) zu erfüllen, es dürfen jedoch nur die offiziell zugelassen Möglichkeiten der deutschen Sprache (also kein Genderstern, Doppelpunkt oder Unterstrich) verwendet werden.

4.7 Barrierefreie Gestaltung

Die folgenden Projektdokumente / Lieferleistungen sind barrierefrei zu erstellen:

− Publikation der Ergebnisse von AP 2, AP 3 und AP 5

− Guideline aus AP 6

− Umsetzungsplan aus AP 7

Dabei sind die Vorgaben der aktuellen Barrierefreie-Informationstechnik-Verordnung (BITV 2.0, https://www.gesetze-im-internet.de/bitv_2_0/BJNR184300011.html) zwingend einzuhalten.

Da sich nur ein von Anfang an gut strukturiertes Dokument ohne größere Probleme in ein barrierefreies PDF umwandeln lässt, ist bereits das Dokument in seinem editierbaren Ursprungsformat barrierefrei zu erstellen. Im Autorendokument (Word) dürfen hierzu durch die softwareeigene Prüfung keine Fehler angezeigt werden. Folgende Anforderungen an das PDF-Endprodukt sind zu erfüllen:

1. Das PDF-Dokument muss für handelsübliche Screenreader geeignet sein und sinnvoll vorgelesen werden können.
2. Das PDF-Dokument muss die Prüfung nach PDF/UA durch den PDF Accessibility Checker (PAC) fehlerfrei bestehen (kostenfreies Tool zur Verwendung auf Windows-PCs).
3. PDFs müssen durch Lesezeichen strukturiert sein.
4. Das Dokument muss über ein getaggtes Inhaltsverzeichnis sowie eine korrekte Überschriftenstruktur verfügen.
5. Die Dokumenteigenschaften müssen fehlerfrei eingetragen und konfiguriert sein (Hauptsprache, Titel, Autor, Tags, Kommentare).
6. Die Lesereihenfolge und die Tag-Struktur müssen sinnvoll angeordnet sein.
7. Alle Bilder (Ausnahme: Hintergrundgrafiken/Artefakte) müssen sinnvolle Titel und Alternativtexte (Bildbeschreibung – keine Bildunterschrift) haben.
8. Bilder und Texte müssen im Wesentlichen kontrastreich verarbeitet werden (z. B. keine dunkle Schrift auf dunklem Hintergrund, gut differenzierbare Verwendung von Farben in Diagrammen, etc.).
9. Listenelemente müssen (auch seitenübergreifend) sinnvoll gegliedert sein
10. Tabellen müssen korrekt ausgezeichnet (Kopfzeilen, Lesereihenfolge) und strukturiert (TH, TD, Colspan, Rowspan) sein.
11. Seitenübergreifende Tabellen müssen als eine Tabelle erkannt werden.
12. Linkverweise zu Webseiten (insbesondere Mehrzeilige) müssen auf korrekte Funktionsweise getestet werden.
13. Die Schriften müssen korrekt im PDF eingebettet sein als „eingebettete Untergruppe“.

Bundesamt für Sicherheit in der Informationstechnik 25

Eine Erläuterung der gesetzlichen Prüfroutine mit allen Details und Hinweisen für Web und PDF-Dateien findet sich unter https://bitvtest.de/test-methodik/web/beschreibung-des-pruefverfahrens.

4.8 Verschlüsselung der Kommunikation

Im Rahmen dieses Projektes erfolgt die E-Mail-Kommunikation (Versand und Empfang) verschlüsselt und signiert nach dem OpenPGP- oder S/MIME-Standard.

Ein Schlüsselaustausch erfolgt im Rahmen der Auftaktbesprechung. Der AN hat dafür Sorge zu tragen, dass der Schlüssel nur auf den zugelassenen Wegen an die Personen des Projektteams verteilt wird.

4.9 Berechtigte Interessen des Herstellers

Zur Untersuchung von informationstechnischen Produkten und Systemen darf sich das BSI gemäß § 7a Abs. 2 BSIG externer Auftragnehmer nur bedienen, soweit berechtigte Interessen des Herstellers der betroffenen Produkte und Systeme dem nicht entgegenstehen. Die Beauftragung eines direkten Konkurrenten (sonstige Hersteller von KI-Tools, die unmittelbar für den Einsatz im Kontext des SSDLC entwickelt wurden) mit der hier beschriebenen Leistung ist somit ausgeschlossen.

Die aus den Untersuchungen gewonnenen Erkenntnisse dürfen seitens des BSI weitergegeben bzw. veröffentlichen werden, soweit dies zur Erfüllung der in § 7a Abs. 2 BSIG genannten Aufgaben erforderlich ist. Vor der Weitergabe bzw. Veröffentlichung der Informationen gibt das BSI dem betroffenen Hersteller unter Berücksichtigung einer angemessenen Frist vorab Gelegenheit zur Stellungnahme.

Nach Abschluss des Projektes sind alle bei der Durchführung des Projektes angefallenen Dokumente und Ergebnisse an das BSI herauszugeben und anschließend beim AN zu löschen. Die Löschung ist dem BSI gegenüber glaubhaft zu machen.

4.10 Einsatz von Unterauftragnehmern

Der AN kann zur Leistungserbringung Unterauftragnehmer nur einsetzen oder eingesetzte Unterauftragnehmer nur auswechseln, wenn der AG dem ausdrücklich vorher zustimmt. Die Zustimmung kann nicht aus sachwidrigen Gründen verweigert werden.

Die Einarbeitung des neuen Unterauftragnehmers erfolgt auf Kosten des AN. Für die im Angebot des AN benannten Unterauftragnehmer gilt die Zustimmung des AG als erteilt.

Die Weitergabe von Projektteilen an nicht zugelassene Unterauftragnehmer ist verboten.

4.11 Anforderungen an die Rechnungsstellung

4.11.1 Zeitpunkt

Um dem AG eine ordnungsgemäße Bewirtschaftung der ihm vom Gesetzgeber zugewiesenen Haushaltsmittel zu ermöglichen, sind die vom AN erbrachten Leistungen frühestmöglich nach Eintreten des entsprechenden vertraglich vereinbarten Meilensteins, spätestens jedoch 30 Kalendertage nach dessen Eintreten, in Rechnung zu stellen.

Bei abnahmefähigen Leistungen setzt das Eintreten eines Meilensteines eine erfolgreiche Abnahme voraus.

26 Bundesamt für Sicherheit in der Informationstechnik

4.11.2 Elektronische Form

Gemäß § 3 i.V.m. § 11 der E-Rechnungsverordnung (E-RechV) sind Rechnungen zwingend in elektronischer Form auszustellen und zu übermitteln. Hierbei ist grundsätzlich der Datenaustauschstandard XRechnung in der jeweils aktuellen Fassung zu verwenden (§ 4 E-RechV).

Erforderliche Anlagen sind immer die Abnahmeprotokolle für die abzurechnenden Leistungen sowie bei Leistungen nach Aufwand zusätzlich die entsprechenden Leistungsnachweise.

Rechnungsformate, welche nicht den Anforderungen der europäischen Norm für die Rechnungsstellung (EN-16931) entsprechen sowie Rechnungen, die nicht über die Rechnungseingangsplattform des Bundes (https://xrechnung-bdr.de) zugestellt wurden, werden nicht berücksichtigt.

Nähere Informationen zu den formalen Anforderungen sind dem in den Vergabeunterlagen enthaltenen Dokument „Die Rechnungseingangsplattformen des Bundes“ (Version September 2025) zu entnehmen.

4.12 Nachhaltige Umsetzung der Leistung

Der AG berücksichtigt bei der Leistungserbringung Nachhaltigkeitsanforderungen, indem er bspw. Dienstreisen reduziert, nachhaltige Energienutzung anwendet, Besprechungen über elektronische Videokonferenzsysteme abhält, Papiereinsparungsmaßnahmen vornimmt und sofern möglich Müll bzw. Elektroschrott bestmöglich vermeidet.

4.13 Bundestariftreuegesetz

Gemäß § 3 des Gesetzes zur Sicherung der Tariftreue bei der Vergabe und Ausführung öffentlicher Aufträge und Konzessionen des Bundes (Bundestariftreuegesetz – BTTG) müssen Bundesauftraggeber ihren Auftragnehmer verbindlich vorgeben, dass der Auftragnehmer die zur Leistungserbringung eingesetzten Arbeitnehmerinnen und Arbeitnehmern für die Dauer, in der sie in Ausführung des öffentlichen Auftrags tätig sind, mindestens die Arbeitsbedingungen gewähren muss, die die jeweils einschlägige Rechtsverordnung nach § 5 BTTG festsetzt.

Bislang ist keine solche Rechtsverordnung erlassen worden. Mit der Angebotsabgabe bestätigen Sie, dass falls eine einschlägige Rechtsverordnung erlassen wird, alle beteiligten Unternehmen ihre im Rahmen dieses Auftrags eingesetzten Arbeitnehmerinnen und Arbeitnehmer darüber informieren, dass für die Dauer des Einsatzes ihr Arbeitsverhältnis mindestens die tariflichen Arbeitsbedingungen nach der einschlägigen Rechtsverordnung, sowie nach dem Bundestariftreuegesetz einzuhalten sind.

Sie sind dann verpflichtet, mittels geeigneter Unterlagen zu dokumentieren, dass Sie ihre Tariftreueversprechen nach § 3 BTTG einhalten. Sie sind außerdem verpflichtet, diese Unterlagen auf Anforderung der Prüfstelle Bundestariftreue vorzulegen. Die Pflicht gilt nicht, sofern die Bedingungen des § 10 BTTG zutreffen. Sie müssen von Unterauftragnehmern und von ihnen oder den Unterauftragnehmern beauftragten Verleihern verlangen und durch geeignete Maßnahmen sicherstellen, dass diese ihre Pflichten nach § 4 Absatz 1 und 3 BTTG erfüllen. Keine Unterauftragnehmer sind unmittelbare oder mittelbare Zulieferer im Sinne von § 2 Abs. 5 Satz 2 Nr. 2 und § i.V.m. Abs. 7 und 8 des Lieferkettensorgfaltspflichtengesetzes, soweit diese Zulieferer keine eigene Verpflichtung des Auftragnehmers erfüllen. Verleiher sind solche nach § 1 Abs. 1 des Arbeitnehmerüberlassungsgesetzes

Stellt die Prüfstelle Bundestariftreue einen Verstoß nach § 13 Bundestariftreuegesetz fest, ist eine Vertragsstrafe in Höhe von 0,5 Prozent, bei mehreren Verstößen maximal 5 % der anteiligen Vergütung verwirkt, die für die bis zur Feststellung des Verstoßes erbrachten Leistungen geschuldet ist oder geschuldet sein wird. Das BSI hat in diesem Fall ein Recht zur außerordentlichen Kündigung.

Bundesamt für Sicherheit in der Informationstechnik 27

B Besondere Bewerbungsbedingungen

5 Bedingungen für die Zuschlagserteilung

In diesem Kapitel sind die Bedingungen für die Zuschlagserteilung festgelegt, die bei der Erstellung eines Angebots gemäß Kapitel 6 zu berücksichtigen sind.

5.1 Gesetzliche Ausschlussgründe, Eignung und

Ausführungsbedingungen

Öffentliche Aufträge werden nur an fachkundige und leistungsfähige (geeignete) Unternehmen vergeben, die nicht nach den §§ 123 oder 124 GWB ausgeschlossen worden sind (§ 122 Abs. 1 GWB, § 31 Abs. 1 UVgO).

Die zwingenden Ausschlussgründe (§ 123 GWB) und die fakultativen Ausschlussgründe (§ 124 GWB) können unter den folgenden Quellen nachgelesen werden:

https://www.gesetze-im-internet.de/gwb/__123.html

https://www.gesetze-im-internet.de/gwb/__124.html

Mit der Abgabe des Angebots erklären die Bieter, dass keine der in §§ 123, 124 GWB genannten Gründe im Hinblick auf ihre Person oder Unternehmen vorliegen, soweit nicht eine Erklärung zu den §§ 123, 124 GWB eingereicht wurde (siehe Kapitel 6.2.4). Das BSI schließt ein Unternehmen jedoch zu jedem Zeitpunkt des Vergabeverfahrens von der Teilnahme aus, wenn es Kenntnis davon erhält, dass ein Ausschlussgrund nach § 123 GWB vorliegt. Ein Ausschluss kommt gleichermaßen bei Kenntnis über einen Ausschlussgrund nach § 124 GWB in Betracht. Die Möglichkeit der Selbstreinigung nach § 125 GWB bleibt unberührt.

Das BSI prüft, ob die Bieter die festgelegten Eignungskriterien (siehe Kapitel 6.2.1.3) und etwaig festgelegte Mindestanforderungen erfüllen (§ 122 Abs. 2 GWB4, § 31 Abs. 2 UVgO). Wird eine Mindestanforderung an die Eignung nicht erfüllt, ist das Angebot auszuschließen. Im Übrigen prüft das BSI auf Grundlage der Eignungskriterien, ob die vorgelegten Belege den Schluss zulassen, dass der Bieter den Auftrag ordnungsgemäß erfüllen kann.

Ausführungsbedingungen betreffen die Vertragsausführung und stellen vom BSI festgelegte Bedingungen dar, die vom AN einzuhalten sind. Der Transparenz halber ist von den Bietern bereits im Vergabeverfahren zu versichern, dass sie im Rahmen der Auftragsausführung die vom BSI vorgesehenen Bedingungen einhalten werden (siehe Angebotsformular, Ziffer 3 „Erklärungen des Bieters“).

5.2 Wirtschaftlichstes Angebot

Der Zuschlag wird auf das wirtschaftlichste Angebot erteilt. Grundlage dafür ist eine Bewertung des BSI, ob und inwieweit das Angebot die vorgegebenen Zuschlagskriterien erfüllt. Das wirtschaftlichste Angebot bestimmt sich nach dem besten Preis-Leistungs-Verhältnis. Zu dessen Ermittlung können neben dem Preis oder den Kosten auch qualitative, umweltbezogene oder soziale Aspekte berücksichtigt werden (§ 127 Abs. 1 GWB, § 43 Abs. 1 und 2 UVgO).

Für die Ermittlung der Wirtschaftlichkeit eines Angebotes wendet das BSI die „erweiterten Richtwertmethode“ über die Faktoren „Bewertungspreis“ (siehe Kapitel 5.2.1) und „Leistung“ (siehe Kapitel 5.2.2) an.

4 Jeweils in Verbindung mit den Regelungen der §§ 42 ff. VgV oder §§ 7, 21 ff VSVgV.

28 Bundesamt für Sicherheit in der Informationstechnik

5.2.1 Bewertungspreis

Der Bewertungspreis umfasst die folgenden Komponenten (siehe auch Kapitel 6.1):

Bewertungspreis = Angebotsnettopreis + anfallende (Einfuhr-/)Umsatzsteuer ohne Rücksicht auf die Steuerschuldnerschaft

Der Angebotsnettopreis umfasst dabei sämtliche Einzelpositionen (siehe Kapitel 3.2, Tabelle 1).

5.2.2 Leistung

Die „Leistung“ der einzelnen Angebote wird vom BSI anhand der festgelegten qualitativen Zuschlagskriterien (siehe Kapitel 6.2.1.4) bewertet.

Bei den qualitativen Zuschlagskriterien wird zwischen Ausschlusskriterien (A-Kriterien) und Bewertungskriterien (B-Kriterien) differenziert.

Während bei einem A-Kriterium lediglich geprüft wird, ob die Ausführungen des Bieters die definierten Mindestanforderungen erfüllen (Prüfergebnis: Ja oder Nein), werden die Ausführungen des Bieters bei einem B-Kriterium anhand einer durchgängigen Wertungsskala von 0 bis 4 Bewertungspunkten (BP) bewertet:

Zur Orientierung werden bei jedem B-Kriterium die Voraussetzungen angegeben, die erfüllt sein müssen, damit das Angebot bzgl. dieses Kriteriums vom BSI mit 0 BP, 1 BP oder 4 BP bewertet wird. Die Bewertung bei Kriterium 2.1 richtet sich allein nach dem in Kapitel 6.2.1.4 Kriterium 2.1 angegebenen Wertungsmaßstab.

Bei den B-Kriterien muss das Angebot jeweils mindestens 1 BP (BP = 1) erzielen (Mindestanforderung). min

Erfüllt ein Angebot bei mindestens einem A-Kriterium oder bei mindestens einem B-Kriterium nicht die definierte Mindestanforderung, so wird dieses Angebot von der Wertung ausgeschlossen.

Bei den verbleibenden Angeboten ergeben sich die für die erweiterte Richtwertmethode maßgeblichen Leistungspunkte (LP) aus dem Produkt der bei den einzelnen B-Kriterien erzielten BP und der vom BSI für die jeweiligen B-Kriterien vorgegebenen Gewichtungsfaktoren (GF, siehe Kapitel 6.2.1.4).

Bundesamt für Sicherheit in der Informationstechnik 29

5.2.3 Erweiterte Richtwertmethode mit dem Entscheidungskriterium

„Leistungspunkte“

Bei der erweiterten Richtwertmethode wird in einem ersten Schritt für jedes der Angebote eine individuelle Kennzahl, welche aus dem Quotient zwischen den erzielten Leistungspunkten (siehe Kapitel 5.2.2) und dem Bewertungspreis (siehe Kapitel 5.2.1) besteht, ermittelt.

Ausgehend vom Angebot mit der höchsten Kennzahl wird in einem nächsten Schritt ein Schwankungsbereich von 10 % definiert. Alle Angebote, die mit Ihrer Kennzahl unterhalb dieses Schwankungsbereiches liegen, können bei der Zuschlagserteilung nicht berücksichtigt werden.

Bei den verbleibenden Angeboten erfolgt die Zuschlagserteilung auf das Angebot mit der höchsten Leistungspunktzahl. Ist die Leistungspunktzahl identisch, erfolgt der Zuschlag auf das preislich günstigere Angebot.

30 Bundesamt für Sicherheit in der Informationstechnik

6 Erstellung des Angebots

Ein vollständiges Angebot besteht aus folgenden Unterlagen:

Angebotsformular (siehe Kapitel 6.1)

Anlagen zum Angebotsformular

Angebotsangaben gemäß den Besonderen Bewerbungsbedingungen (siehe Kapitel 6.2.1). Wird im Rahmen einzelner Eignungskriterien und / oder Zuschlagskriterien explizit die Einreichung weiterer Dokumente (z.B. Kopie einer offiziellen Bescheinigung oder eines amtlichen Nachweises, etc.) gefordert, so sind diese nach Möglichkeit an der entsprechenden Stelle in diese Anlage zu integrieren. Ist eine Integration nicht möglich, so bilden diese eine eigenständige Anlage.

ggf. Bietergemeinschaftserklärung (siehe Kapitel 6.2.2)

ggf. Unterauftragnehmerverpflichtungserklärung (siehe Kapitel 6.2.3)

ggf. Angaben zu vorliegenden Ausschlussgründen und zur Selbstreinigung im Sinne von § 125 GWB (siehe Kapitel 6.2.4)

ggf. weitere individuelle Anlagen des Bieters (siehe Kapitel 6.2)

Die Anzahl der geforderten Anlagen ist dabei abhängig von der Bieterkonstellation (siehe Kapitel 6.2.2), der geplanten Einbindung von Unterauftragnehmern (siehe Kapitel 6.2.3) sowie dem Vorliegen von gesetzlichen Ausschlussgründen (siehe Kapitel 6.2.4).

Das BSI ist rechtlich verpflichtet, die eingereichten Angebote mindestens drei Jahre ab dem Tag der Zuschlagserteilung aufzubewahren. Reichen Sie daher alle für die Angebotswertung relevanten Informationen in archivierbarer Form ein. Verzichten Sie z.B. in der Anlage „Angebotsangaben gemäß den Besonderen Bewerbungsbedingungen“ auf die Angabe von URLs bzw. auf deren Verweisung.

Bitte fügen Sie nach Möglichkeit alle Anlagen zum Angebotsformular zu einer „Gesamtdatei“ (PDF) zusammen (jedoch ohne das Angebotsformular, vgl. Kapitel 6.1).

6.1 Angebotsformular

Das in den Vergabeunterlagen enthaltene Angebotsformular ist gemäß den dort aufgeführten Vorgaben auszufüllen.

Ist die Steuerschuldnerschaft aufgrund von § 13b USTG auf den AG übergegangen (reverse charge), so weisen Sie im Angebot einen Steuersatz von 0 % aus. In diesem Fall wird die von AG abzuführende Umsatzsteuer bei der Bewertung des Angebotes berücksichtigt (siehe Kapitel 5.2.1).

Verschiedene Eingabefelder des Angebotsformulars werden nach Abgabe und Öffnung des Angebotes maschinell ausgelesen. Verzichten Sie daher auf die Einreichung eines eingescannten Auftragsformulars und auf die Zusammenfassung des Angebotsformulars mit den zugehörigen Anlagen zu einer „Gesamtdatei“.

6.2 Anlagen zum Angebotsformular

Die nachfolgenden Unterkapitel geben einen Überblick über die einzelnen Anlagen sowie über deren inhaltliche Anforderungen.

Falls aus Sicht des Bieters erforderlich, so kann das Angebot um weitere Anlagen ergänzt werden.

Alle zum Angebot gehörenden Anlagen sind auf Seite 2 des Angebotsformulars aufzuführen.

Bundesamt für Sicherheit in der Informationstechnik 31

6.2.1 Anlage: Angebotsangaben gemäß den Besonderen

Bewerbungsbedingungen

Die von jedem Bieter individuell zu erstellende Anlage „Angebotsangaben gemäß den Besonderen Bewerbungsbedingungen“ fungiert neben dem Angebotsformular als zentraler Bestandteil des Angebotes.

Halten Sie sich bei der Erstellung dieser Anlage an die Vorgaben in den Kapiteln 6.2.1.1 bis 6.2.1.4 sowie an die vorgegebene Reihenfolge. Achten Sie darauf, die geforderten Angaben unmittelbar bei den einzelnen Kriterien aufzuführen.

Achtung: Verzichten Sie auf nicht geforderte Angaben, insbesondere zu den vertraglichen Regelungen (siehe Ziffer 4.2 der Allgemeinen Bewerbungsbedingungen).

Die vollständige Abdeckung des in der Leistungsbeschreibung geforderten Leistungsumfangs inkl. der Einhaltung sämtlicher in Kapitel 4 der Leistungsbeschreibung definierten Rahmen- und Ausführungsbedingungen wird durch Abgabe eines Angebotes automatisch bestätigt (siehe Angebotsformular, Ziffer 3 „Erklärungen des Bieters“).

6.2.1.1 Einzelbieter / Mitglieder der Bietergemeinschaft

Erstellen Sie vom Einzelbieter bzw. vom jedem Mitglied der Bietergemeinschaft ein aussagekräftiges Firmenprofil. Die Darstellung muss in tabellarischer Form erfolgen und folgende Punkte umfassen:

Offizielle Bezeichnung

Rechtsform

Firmensitz und Standorte

Struktur und Organisation

z.B. Abbildung des Organigramms

Geschäftsfelder

Auflistung der einzelnen Geschäftsfelder

Benennung der Geschäftsfelder, die für den hier zu vergebenden Auftrag relevant sind (auftragsbezogene Geschäftsfelder)

ggf. nähere Ausführungen / Erläuterungen zu den auftragsbezogenen Geschäftsfeldern

Anzahl der Mitarbeiter in den auftragsbezogenen Geschäftsfeldern

Gesamtumsatz in den letzten drei Geschäftsjahren (Angabe pro Jahr), sofern entsprechende Angaben verfügbar sind.

Umsatz in den auftragsbezogenen Geschäftsfeldern in den letzten drei Geschäftsjahren (Angabe pro Jahr), sofern entsprechende Angaben verfügbar sind.

Gehen Sie im Falle einer Bietergemeinschaft zudem auf die Aufteilung der zu erbringenden Leistung auf die einzelnen Mitglieder der Bietergemeinschaft ein.

6.2.1.2 Unterauftragnehmer

Werden wesentliche Teile der angebotenen Leistung von einem oder mehreren Unterauftragnehmern erbracht (siehe Ziffer 2.1 des Angebotsformulars), so sind diese Unternehmen inkl. der von ihnen durchzuführenden Leistungen genau zu benennen. Erstellen Sie von jedem Unterauftragnehmer zudem ein aussagekräftiges Firmenprofil inkl. der folgenden Angaben:

32 Bundesamt für Sicherheit in der Informationstechnik

Offizielle Bezeichnung

Rechtsform

Firmensitz und Standorte

auftragsbezogene Geschäftsfelder

Anzahl der Mitarbeiter in den auftragsbezogenen Geschäftsfeldern

durchzuführende Leistungen

Wird die Leistung ohne Mitwirkung von einem oder mehreren Unterauftragnehmern erbracht, so geben Sie an dieser Stelle Ihres Angebotes bitte lediglich „Kein Unterauftragnehmer“ an.

Die Weitergabe von wesentlichen Projektteilen an nicht genannte Unterauftragnehmer ist verboten.

6.2.1.3 Eignungskriterien

Bundesamt für Sicherheit in der Informationstechnik 33

34 Bundesamt für Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik 35

6.2.1.4 Qualitative Zuschlagskriterien

36 Bundesamt für Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik 37

38 Bundesamt für Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik 39

40 Bundesamt für Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik 41

42 Bundesamt für Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik 43

6.2.2 Anlage: Bietergemeinschaftserklärung

Wird das Angebot von einer Bietergemeinschaft abgegeben, so ist dem Angebot eine entsprechende Erklärung beizufügen (siehe standardisiertes Formular in den Vergabeunterlagen). Diese Erklärung ist von allen Mitgliedern der Bietergemeinschaft zu signieren (siehe Ziffern 3.4.2 und Ziffer 6.2 der Allgemeinen Bewerbungsbedingungen).

6.2.3 Anlage: Unterauftragnehmerverpflichtungserklärung(en)

Sollen wesentliche Teile der angebotenen Leistung von einem oder mehreren Unterauftragnehmern für den Bieter erbracht werden, so ist dem Angebot pro Unterauftragnehmer eine entsprechende Verpflichtungserklärung beizufügen (siehe standardisiertes Formular in den Vergabeunterlagen). Diese sind von den Unterauftragnehmern zu signieren (siehe Ziffern 3.4.2 und Ziffer 6.3 der Allgemeinen Bewerbungsbedingungen).

44 Bundesamt für Sicherheit in der Informationstechnik

6.2.4 Anlage: Angaben zu vorliegenden Ausschlussgründen und zur

Selbstreinigung im Sinne von § 125 GWB

Liegt mindestens ein zwingender oder fakultativer gesetzlicher Ausschlussgrund bei dem Bieter, bei einem Mitglied der Bietergemeinschaft oder bei einem Unterauftragnehmer vor (siehe Kapitel 5.1), so ist dem Angebot eine entsprechende Erklärung als Anlage beizufügen. Diese muss mindestens die folgenden Angaben enthalten:

Abschließende Auflistung aller vorliegenden Ausschlussgründe im Sinne von den § 123 und § 124 GWB

Detaillierte Erläuterungen zu den vorliegenden Ausschlussgründen. Insbesondere enthalten die Erläuterungen Angaben zur Art der Straftat, zur Höhe des fraglichen Betrages, zum Datum einer rechtskräftigen Gerichtsentscheidung / bestandskräftigen Verwaltungsentscheidung, zur Dauer des festgelegten Ausschlusszeitraums sowie zu den eingegangenen Verpflichtungen im Sinne von § 123 Abs. 4 Satz 2 GWB.

Getroffene Maßnahmen zur Selbstreinigung im Sinne von § 125 GWB.

Die Anlage ist zu signieren (siehe Ziffern 3.4.2 der Allgemeinen Bewerbungsbedingungen).

Bundesamt für Sicherheit in der Informationstechnik 45

C Abkürzungsverzeichnis5

5 Das Abkürzungsverzeichnis erhebt keinen Anspruch auf Vollständigkeit. Auch kann dieses standardisierte Verzeichnis ggf. Abkürzungen und Begriffe zu inhaltlichen Punkten enthalten, die nicht Gegenstand der hier vorliegenden Leistungsbeschreibung sind (z.B. SÜG).

46 Bundesamt für Sicherheit in der Informationstechnik

D Muster Leistungsnachweis

Im Folgenden finden Sie ein Beispiel für den Aufbau eines Leistungsnachweises und welche Informationen dieser erhalten sollte. Auf Wunsch wird das Muster als elektronisches Dokument nach Auftragsvergabe von der Projektleitung zur Verfügung gestellt.

Hinweis: Leistungsnachweise müssen ausschließlich bei Vergütung nach Aufwand mit der Rechnung eingereicht werden.

Bundesamt für Sicherheit in der Informationstechnik 47