Während der Lebenszyklus der Softwarelieferkette vom Quellcode bis hin zu ausführbaren Artefakten fortschreitet, stellt die Build-Phase einen kritischen Wendepunkt dar. Diese transformative Phase ist jedoch auch anfällig für eine Reihe von Bedrohungen, die die Integrität der Software gefährden können und build security. Diese Bedrohungen können den Build-Prozess auf verschiedene Weise infiltrieren, einschließlich der Umgehung der etablierten CI/CD pipeline, das Modifizieren von Code nach der Quellcodeverwaltung, das Kompromitieren des Build-Prozesses selbst oder das Manipulieren von Artefakt-Repositories. In diesem Blogbeitrag gehen wir ausführlich auf diese Bedrohungen ein und untersuchen die häufigsten Angriffe auf Software-Lieferketten-Builds. Dieser Inhalt setzt unsere Blogserie fort, in der wir software supply chain security während die SDLC.
Die Build-Phase im Softwareentwicklungszyklus
Die Build-Phase des Software-Lieferkettenlebenszyklus umfasst den Prozess der Umwandlung von Quellcode in ausführbare Softwareartefakte. Diese Phase umfasst das Kompilieren, Verknüpfen und Verpacken des Quellcodes sowie das Generieren von Installationspaketen und Konfigurationsdateien.
Build security Bedrohungen sind Schwachstellen, die es einem Angreifer ermöglichen könnten, während des Build-Prozesses unbefugte Änderungen an der Software vorzunehmen, ohne den Quellcode zu verändern. Diese Bedrohungen können auf verschiedene Weise eingeführt werden, beispielsweise durch die Kompromittierung der Build-Umgebung oder die Ausnutzung von Schwachstellen in Build-Tools.
Die häufigsten Bedrohungen für die Software-Lieferkette - Build-Angriffe
Umgehen CI/CD
Damit ist die Praxis gemeint, die etablierten CI/CD (kontinuierliche Integration und kontinuierliche Bereitstellung) pipeline Software direkt zu erstellen und zu veröffentlichen, ohne die strengen Test-, Verifizierungs- und Auditprozesse zu durchlaufen, die normalerweise von den offiziellen pipelineDies kann durch manuelles Erstellen der Software außerhalb des CI/CD Umgebung oder durch die Verwendung von Tools oder Skripten, die unbefugte Änderungen am Build-Prozess ermöglichen. Ein Beispiel für diese Art von Vektorangriff war der Jenkins-Angriff. Im Jahr 2022 infiltrierten Hacker den Build pipeline eines beliebten Open-Source-Softwareprojekts namens Jenkins. Die Hacker injizierten Schadcode in eine Jenkins-Datei, ein Skript, das den Build-Prozess definiert. Der Schadcode ermöglichte es den Hackern, die CI/CD pipelineSicherheitsprüfungen und fügen ihren Code in den Build-Prozess ein. Dieser Code wird dann auf den Systemen der Organisationen ausgeführt, die die Software installiert haben.
Ändern des Codes nach der Quellcodeverwaltung
Bei dieser Vorgehensweise werden unberechtigte Änderungen am Quellcode vorgenommen, nachdem dieser committed an ein vertrauenswürdiges Quellcodeverwaltungssystem (SCS) und dann die Software mit diesem geänderten Code erstellen. Dies kann durch direkte Änderung des Codes auf der Workstation eines Entwicklers oder durch Verwendung externer Tools oder Skripte erfolgen, um Schadcode in den Build-Prozess einzuschleusen. Ein Beispiel für diesen Vektorangriff war der GitLab-Angriff im Jahr 2022. Hacker infiltrierten den Build pipeline of GitlabDie Hacker haben Schadcode in das GitLab eingeschleust CI/CD pipeline, ein Tool zur Automatisierung der build security Prozess. Der bösartige Code ermöglichte es den Hackern, den Code zu ändern, nachdem er in die Quellcodeverwaltung eingecheckt worden war. Dadurch konnten sie ihren Code in die Software einschleusen, der dann auf den Systemen der Organisationen ausgeführt wurde, die die Software installiert hatten.
Kompromittierungs-Build-Prozess
Dabei wird der Build-Prozess selbst manipuliert oder geändert, entweder durch direkten Zugriff auf die Build-Umgebung oder durch Ausnutzen von Schwachstellen in Build-Tools oder Abhängigkeiten von Drittanbietern. Dies kann dazu führen, dass bösartiger Code in die Build-Ausgabe eingebracht wird, die Build-Herkunft manipuliert wird oder der Build-Prozess insgesamt unterbrochen wird. Das bekannteste Beispiel für diesen Vektorangriff war der SolarWinds-Angriff. Ein Angreifer hatte sich unbefugten Zugriff auf die Build-Plattform von SolarWinds verschafft, ein System, das zum Kompilieren und Verpacken der SolarWinds Orion-Software verwendet wird. Dieses Skript injizierte Schadcode in die kompilierte SolarWinds Orion-Software. Als Benutzer die kompilierte Software installierten, wurde der Schadcode auf ihren Systemen ausgeführt, wodurch der Angreifer unbefugten Zugriff auf ihre Systeme erhielt. Der Angreifer konnte außerdem vertrauliche Daten aus ihren Systemen stehlen, wie z. B. Anmeldeinformationen, geistiges Eigentum und Kundeninformationen.
Kompromittierungsartefakt-Repository
Dies bezieht sich auf den unbefugten Zugriff oder die Manipulation eines Artefakt-Repositorys, in dem Softwarepakete und Binärdateien zur Verteilung an interne oder externe Benutzer gespeichert sind. Angreifer können diese Sicherheitsanfälligkeit ausnutzen, um Schadcode einzuschleusen, die Authentizität der Software zu manipulieren oder den Bereitstellungsprozess zu stören. Ein Beispiel für diesen Vektorangriff war Die RubyGems im Jahr 2022. Hacker infiltrierten das Artefakt-Repository von RubyGems. Die Hacker ersetzten ein legitimes Artefakt durch ein bösartiges, das dann von Tausenden von Organisationen heruntergeladen wurde, die Software mit Ruby on Rails erstellen. Das bösartige Artefakt ermöglichte es den Hackern, beliebigen Code auf den Systemen der Organisationen auszuführen, die die Software installiert hatten. Dies könnte es ihnen möglicherweise ermöglichen, Daten zu stehlen, Malware zu installieren oder den Betrieb zu stören.
Schlussbemerkungen
Da Unternehmen immer mehr Softwareentwicklungsmethoden anwenden, die Automatisierung und kontinuierliche Bereitstellung betonen, war die Absicherung des Softwareerstellungsprozesses noch nie so wichtig. Durch die Implementierung robuster Sicherheitsmaßnahmen während der gesamten Erstellungsphase können Unternehmen ihr Risiko, Opfer böswilliger Angriffe zu werden, die die Integrität und Sicherheit ihrer Software gefährden können, erheblich senken.
Die in diesem Blogbeitrag beschriebenen Strategien und die bereitgestellten Beispiele erinnern daran, dass die Build-Phase ein anfälliger Punkt in der Software-Lieferkette ist. Unternehmen sollten diese Bedrohungen berücksichtigen und die erforderlichen Sicherheitsmaßnahmen ergreifen, um ihre Software vor Angriffen zu schützen. Auf diese Weise können sie die Integrität, Sicherheit und Zuverlässigkeit ihrer Software für ihre Benutzer und Kunden gewährleisten.
Begleiten Sie uns auf unserem Weg zu einem sicheren Software-Ökosystem
Verpassen Sie nicht die Gelegenheit, Bedrohungen in der Software-Lieferkette immer einen Schritt voraus zu sein. Abonnieren Sie noch heute unseren Blog und erhalten Sie als Erster unsere neuesten Erkenntnisse, damit Ihr Unternehmen trotz sich entwickelnder Bedrohungen widerstandsfähig und sicher bleibt. Gemeinsam können wir ein robusteres und sichereres Software-Ökosystem für alle aufbauen.
Sehen Sie sich unsere Video-Demo an
