- Präsident Joe Biden hat am 23. Dezember den SHARE IT Act unterzeichnet. Damit müssen US-Bundesbehörden individuell entwickelten Quellcode untereinander teilen, um doppelte Entwicklungsaufträge zu reduzieren.
- Kern des Gesetzes ist es, die geschätzt rund 12 Mrd. US-Dollar, die die Bundesregierung jährlich für Softwarekäufe ausgibt, zu senken, indem behördenspezifischer Custom Code öffentlich katalogisiert und wiederverwendbar gemacht wird.
- Vom Anwendungsbereich ausgenommen sind geheimer Code, nationale Sicherheitssysteme sowie Code, bei dessen Weitergabe Datenschutzrisiken entstehen könnten.
- Die CIOs der Behörden müssen innerhalb von 180 Tagen nach Inkrafttreten Umsetzungsrichtlinien erstellen, einschließlich der Einhaltung von Best Practices, der Veröffentlichung von Metadaten und standardisierten Berichtsverfahren.
- Atlassian und GitLab Inc. unterstützten den Gesetzentwurf; er wurde im Dezember in Senat und Repräsentantenhaus ohne namentliche Abstimmung verabschiedet.
Pflicht zur Code-Freigabe im SHARE IT Act
- Der Source Code Harmonization And Reuse in Information Technology Act, kurz SHARE IT Act, verpflichtet Bundesbehörden, von ihnen individuell entwickelten Quellcode mit anderen Behörden zu teilen.
- Im Fokus steht die Verringerung von doppelter Entwicklung, bei der Code erneut per Auftrag erstellt wird, obwohl er bereits für eine andere Behörde entwickelt wurde.
- Behörden müssen Custom Code öffentlich katalogisieren und anderen Behörden ermöglichen, diesen Code zu nutzen.
Ziel der Kostensenkung und Ausnahmen vom Anwendungsbereich
- Die Unterstützer des Gesetzentwurfs schätzen, dass die Bundesregierung jährlich rund 12 Mrd. US-Dollar für Softwarekäufe ausgibt.
- Der SHARE IT Act soll diese Kosten durch die Wiederverwendung von Custom Code senken.
- Folgender Code ist vom Anwendungsbereich des Gesetzes ausgenommen:
- geheimer Code
- nationale Sicherheitssysteme
- Code, der bei Weitergabe Datenschutzrisiken verursachen könnte
Pflicht der Behörden-CIOs zur Richtlinienerstellung binnen 180 Tagen
- Die Chief Information Officers (CIOs) der Behörden müssen innerhalb von 180 Tagen nach Inkrafttreten des Gesetzes Richtlinien zur Umsetzung des SHARE IT Act erstellen.
- Die Richtlinien müssen folgende Verfahren enthalten:
- Verfahren, die sicherstellen, dass individuell entwickelter Code Best Practices entspricht
- Verfahren zur öffentlichen Bereitstellung der Metadaten von Custom Code
- standardisierte Berichtsverfahren
Zu veröffentlichende Metadaten
- Die im Gesetz genannten Metadaten umfassen Informationen, mit denen sich der Entwicklungs- und Freigabestatus von Custom Code nachvollziehen lässt.
- Dazu gehören:
- ob der Custom Code im Rahmen eines Vertrags entwickelt wurde
- ob der Code in einem Repository geteilt wurde
- die Vertragsnummer
- ein Hyperlink zu dem Repository, in dem der Code geteilt wurde
Gesetzgebungsverlauf und Unterstützung aus der Branche
- Der Gesetzentwurf wurde im Senat von Ted Cruz und Gary Peters sowie im Repräsentantenhaus von Nicholas Langworthy und William Timmons unterstützt.
- Senat und Repräsentantenhaus verabschiedeten den Entwurf im Dezember ohne aufgezeichnete Ja-/Nein-Abstimmung.
- Laut Langworthys Ankündigung zur Einbringung im Repräsentantenhaus im September unterstützten Atlassian und GitLab Inc. den Gesetzentwurf.
- Atlassians Chefjurist Stan Shepard sieht in mehr Zusammenarbeit und Austausch bei Custom Code einen Treiber für Offenheit, Effizienz und Innovation in der gesamten Bundesverwaltung.
1 Kommentare
Kommentare auf Hacker News
Ohne Erfahrung in der Verwaltung hat man vielleicht kein Gefühl dafür, warum das so schwierig ist. Das Militär ist allergisch gegen interne Software, und Militär-IT ist eine völlig andere Welt, die täglich von staatlich unterstützten Angreifern auf Weltklasseniveau attackiert wird.
Startups erleben so etwas nicht, und selbst Großkonzerne wie Facebook machen nur annähernd vergleichbare Erfahrungen in Bezug auf die Kritikalität; im zivilen Bereich kommen dem am ehesten große Finanzinstitute nahe. Die US-Streitkräfte sind außerdem der größte einzelne Arbeitgeber der Welt, etwa so groß wie 4,5 Walmart-Konzerne.
Deshalb überwacht das Militär alles auf mehreren Ebenen und schottet es mit genehmigten Softwarelisten pro Ebene stark ab. Die Leute, die Sicherheitsrichtlinien schreiben oder deren Einhaltung überwachen, sind wahrscheinlich keine erfahrenen Software-Direktoren; wenn sie NPM oder Maven sehen, betrachten sie das als unbegrenzten Angriffsvektor, geschaffen von Leuten ohne Sicherheitsverständnis – und ganz falsch liegen sie damit auch nicht.
Im zivilen und Contractor-Bereich ist auch das Eigentum am Code kompliziert. Wenn etwas mit Regierungsgeld entwickelt wird, sollte es der Regierung gehören, aber Auftragnehmer meinen, sie müssten es als eigenes, von der Regierung getrenntes Asset behalten, um es erneut abrechnen zu können. Wenn Subunternehmer nicht zu den finanziellen Zielen des Hauptauftragnehmers passen, wird es noch komplizierter. Persönlich denke ich, man sollte einfach alles der Regierung übergeben, aber es ist seltsam, wie viele Barrieren die Leute auf mehreren Ebenen errichten. Die Infrastruktur auf Regierungsseite hat ein deutlich höheres Niveau an Sicherheitszertifizierungen und ist daher im Allgemeinen auch weniger eingeschränkt.
Einige Bereiche des US-Militärs mögen dem beschriebenen Bedrohungsniveau und der entsprechenden Sicherheitsraffinesse ausgesetzt sein, insgesamt gibt es aber viele Legacy-Systeme, in die sich moderne Lösungen oder Best Practices nur schwer integrieren lassen. Solche veralteten Systeme, Arbeitsabläufe und Bürokratien erzeugen eher Ineffizienz und Schwachstellen als herausragende Sicherheit.
Dass man nichts von Kompromittierungen des US-Militärs hört, liegt nicht daran, dass sie nicht passieren, sondern daran, dass sie nach ihrem Auftreten als geheim eingestuft werden. Öffentliche Blamage zu vermeiden ist der wichtigste Zweck von Geheimhaltung, wodurch der Eindruck von Kompetenz entsteht. Ich würde Facebooks Sicherheit jederzeit über die des US-Militärs stellen, und zwar mit deutlichem Abstand. Facebook ist zudem auch ein Zahlungsabwickler.
Angesichts der Bedeutung von AWS ist klar, dass Amazon ähnlichen Bedrohungen ausgesetzt sein dürfte.
(A) Allgemeine Bestimmung – Dieses Gesetz gilt nicht für geheimen Quellcode oder für Quellcode, der hauptsächlich für die Nutzung in einem nationalen Sicherheitssystem gemäß Definition in 40 U.S.C. 11103 entwickelt wurde.
(B) Nationale Sicherheit – Die Ausnahme von den Anforderungen in Abschnitt 3 gilt für geheimen Quellcode oder für folgenden Quellcode: (i) Code, der hauptsächlich für die Nutzung in einem nationalen Sicherheitssystem entwickelt wurde, oder (ii) Code, der von einer Einrichtung der Intelligence Community gemäß Definition in Abschnitt 3(4) des National Security Act von 1947 oder einem Teil davon entwickelt wurde.
Damals verstand ich, wie das Geschäft mit Regierungsaufträgen strukturiert ist und warum Dinge jahrelang länger dauern als nötig.
Man fragt sich: Es ist doch Geld, das wir mit unseren Steuern bezahlen – warum sollte man also ein Modell unterstützen, das allen in die Tasche greift, um ein paar Schwergewichte und Vertriebler des Unternehmens sehr reich zu machen?
Wenn die Haltung lautet: „Wir werden der Regierung nicht alles geben“, dann wäre ein vernünftiger Ansatz meiner Meinung nach, der Regierung das Recht einzuräumen, die Arbeitsergebnisse nach Wunsch zu nutzen, während nicht geheime Komponenten und deren Derivate frei an den Privatsektor verkauft werden dürfen.
Das Gesetz verlangt, dass die CIOs der Behörden innerhalb von 180 Tagen nach Inkrafttreten Richtlinien erstellen. Diese Richtlinien sollen sicherstellen, dass individuell entwickelter Code den Best Practices entspricht, und Verfahren zur Veröffentlichung von Metadaten zu individuellem Code sowie standardisierte Berichtsverfahren festlegen.
Nach dem neuen Gesetz umfassen die Metadaten, ob individueller Code per Vertrag entwickelt wurde, ob er in einem Repository geteilt wurde, die Vertragsnummer sowie einen Link zu dem Repository, in dem der Code geteilt wurde.
Leider scheint das Gesetz nicht zu verlangen, dass Behörden den Code öffentlich als Open Source bereitstellen, sondern nur eine behördenübergreifende Weitergabe. Öffentlich geteilt werden müssen offenbar nur die „Metadaten“. Der vollständige Gesetzestext steht unter https://www.congress.gov/bill/118th-congress/house-bill/9566...
Es gibt Ausnahmen, aber es gab auch die Argumentation, dass andere Auftragnehmer in der Lage bleiben müssen, den Source Code zu verändern und ihn ebenfalls nicht zu veröffentlichen. Ich vermute, das hängt mit dem Verteidigungsbereich zusammen.
Um ihn aus finanziellen Gründen privat zu halten, lag die Messlatte hoch, aber ihn aus irgendeinem anderen Grund privat zu halten, war immer möglich. DOE Code ist ein Programm zur Nachverfolgung von Open-Source-Software und wird üblicherweise über GitHub-Organisationen verwaltet. OSTI ist die Abteilung, die sämtliches geistiges Eigentum und Forschung nachverfolgt.
Das Open-Source-Entwicklungsmodell war auch für LLNL von Vorteil, und sie haben eine deutlich bessere Codebasis bekommen, als wenn sie allein daran entwickelt hätten.
Manches ist bereits veröffentlicht, etwa NASA IKOS: https://github.com/NASA-SW-VnV/ikos
Dieses Projekt bekommt von Dritten viel weniger Aufmerksamkeit, als es verdienen würde. Wenn es sich zu einem allgemeinen, sound Static Analyzer entwickeln könnte, der Multithreading behandelt, würde das zur Verbesserung vieler anderer Projekte beitragen.
Ich habe einmal versucht, ein vollständiges Open-Source-Modell voranzutreiben, nach dem Gedanken: „Wenn es aus öffentlichen Mitteln finanziert wird, sollte die Öffentlichkeit die daraus entstandenen Ergebnisse sehen“: https://web.archive.org/web/20200920095030/http://oss4gov.or...
Ich war der Ansicht, dass Open Source der Standard für Regierungssoftware sein sollte, sofern es keine Ausnahme mit Zustimmung auf Ministerebene gibt. Allerdings war ich damals jung und naiv.
Ghidra ist ein gutes Beispiel, und dass diese Software kostenlos wurde, war ein großer Gewinn für die Security-Community.
Wir entwickeln Open-Source-Software und versuchen, sie von Regierungsbehörden übernehmen oder nutzen zu lassen, aber es ist erstaunlich, wie sehr diese Behörden offenbar allergisch gegen Open Source sind.
Manche bauen lieber selbst Legacy-Lösungen wie CSV-Uploads oder kaputte Parser, statt den Code anderer zu verwenden, und erzeugen dabei die vorhersehbaren Bugs und Defekte gleich mit.
Auch bei Antworten auf Ausschreibungen wird Open Source stärker geprüft als geschlossene Systeme. Wenn es offen ist, muss man beweisen, dass das gut ist; wenn es geschlossen ist, kann der Anbieter sagen: „Ja, es ist perfekt“, und die Behörde kann das durchwinken. Es wirkt, als wollten die Behörden und ihre Mitarbeiter keinerlei Verantwortung übernehmen. Trotzdem habe ich noch nie erlebt, dass jemand wegen Inkompetenz seinen Regierungsjob verloren hätte.
Ich arbeite in der Regierung und habe das selbst erlebt. Die Kultur ist hochtoxisch und kaputt. Ich bin gespannt, welche Änderungen das Team von Elon und Trump vorschlagen wird.
Das US-Verteidigungsministerium hat eine FAQ zu Open-Source-Software: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx und https://github.com/risacher/DoD-OSS-FAQ
Diese Version wurde als Experiment mit einem kollaborativen Tool für öffentliche Beteiligung an Regierungsrichtliniendokumenten auf GitHub veröffentlicht; dort heißt es, dass militärisches und ziviles Personal, Auftragnehmer sowie Zivilpersonen per Pull Request Änderungen oder Ergänzungen vorschlagen können.
Video von 2010: https://www.youtube.com/watch?v=WWt0YiXcEkE
Dan Risacher aus dem Büro des DoD CIO und der Open-Source-Sicherheitsexperte David A. Wheeler erläutern die Geschichte und die Auswirkungen eines jüngeren DoD-Memos, in dem klargestellt wird, dass das Verteidigungsministerium Open Source als praktikable Form kommerzieller Software ansieht.
Material von 2024: https://openssf.org/press-release/2024/10/29/openssf-expands...
Die OpenSSF der Linux Foundation erklärte, sie erkenne den Bedarf an Sicherheitsschulungen an; laut David A. Wheeler, Director of Open Source Supply Chain Security bei OpenSSF, haben sich seit Start des Kurses mehr als 25.000 Personen für diese Schulungsmaterialien registriert.
Die Absicht ist gut, aber in der Praxis wird wohl nicht viel passieren, außer dass potenzielle Wettbewerber von Auftragnehmer 1 den Rückstand aufholen oder auf Basis der Qualität des bestehenden Vertragscodes angreifen. Code zu lesen ist schwieriger, als Code zu schreiben.
Wenn sie auf Basis der Qualität des bestehenden Vertragscodes angreifen, ist das Code Review und führt in irgendeiner Form zu besserer Codequalität. Ich sehe nicht, wo hier das Problem liegt.
Das ist großartig. Ich erinnere mich daran, wie mühsam es sogar innerhalb derselben Organisation war, Code lesen zu können. Solche Änderungen dürften denjenigen die Arbeit erleichtern, die Top-down-Mentalmodelle erstellen.
Grundsätzlich sollte alles, was mit Steuergeld bezahlt wurde, öffentlich sein. Public Monies Public Goods sollte das absolute Grundprinzip sein.
Das hindert unethische Auftragnehmer allerdings nicht daran, Code urheberrechtlich zu schützen und Lizenzgebühren zu verlangen. Das gilt für den Großteil des DoE-Codes; NWCHEM ist eine der Ausnahmen. Ich habe mich immer gefragt, warum daraus keine Klagen entstanden sind – vermutlich, weil es niemanden wirklich groß interessiert hat.
Einerseits kann ich verstehen, dass man darin sieht, wie andere Regionen auf einem Verordnungssystem mitfahren, das von den Steuerzahlern vor Ort finanziert wurde. Umso mehr, wenn diese Gesetze hauptsächlich für die lokale Kommunalverwaltung gelten. Andererseits fühlt es sich merkwürdig an, dass Gesetze durch Urheberrecht beschränkt werden.
Man sollte auch darüber nachdenken, was man genau besitzt, wenn man zu Hause jemanden mit einer Arbeit beauftragt – abgesehen vom Endprodukt.
Eine hervorragende Richtung. Bei der Arbeit mit Regierungsteams habe ich gesehen, dass ein solcher Ansatz als empfohlene Praxis genannt wurde: https://www.forgov.qld.gov.au/information-and-communication-...
In vielen Fällen ist aber weiterhin der Schritt nötig, diese Empfehlung als Anforderung gesetzlich zu verankern, damit sie tatsächlich befolgt wird. Das gilt besonders im öffentlichen Dienst, wo es häufig Menschen gibt, die noch nie an einer Open-Source-Community teilgenommen haben.
Wie andere betont haben, sollten öffentliche Mittel zu öffentlichem Nutzen führen, und Open Source ist ein guter Weg, diesen Nutzen zu vergrößern.
Es gibt die Formulierung: „Das neue Gesetz gilt nicht für geheimen Code, nationale Sicherheitssysteme oder Code, dessen Weitergabe Datenschutzrisiken verursachen würde.“
Was für eine Art Code soll denn Datenschutzrisiken verursachen, wenn man ihn teilt? Das klingt, als wären Code und Daten ziemlich übel miteinander vermischt.
Regierungsauftragnehmer geben zwischen den Zeilen gern zu, dass ihr Code mies ist und sich im Wesentlichen auf Security through Obscurity verlässt. Auch die Informationskommission hat ihnen einige Male recht gegeben.
Man kann sich zum Beispiel überlegen, was man in Excel-Formeln sehen könnte.