Snyks Shift-left-Ansatz für die API-Entwicklung

Die Developer-Security-Plattform von Snyk bietet Entwicklern und Sicherheitsexperten die Tools, die sie benötigen, um moderne Anwendungen sicher zu entwickeln und zu betreiben. Snyk ermöglicht es Nutzern, Sicherheitsprüfungen nach links zu verlagern und ein DevSecOps-Modell einzuführen. Teams für die Entwicklung moderner Anwendungen wissen: Shift left bedeutet, Entwicklern so früh wie möglich im Entwicklungsprozess Informationen zur Verfügung zu stellen, damit effiziente und sichere Anwendungen und Entwicklungsprozesse entstehen.

Bei Snyk verfolgen wir denselben Shift-left-Ansatz bei der Entwicklung der APIs und Anwendungen, die unsere Plattform antreiben. Die API-Entwicklung erfordert wie andere spezialisierte Aufgaben die Entwicklung spezifischer Prozesse und den Einsatz geeigneter Tools. Als API-first-Plattform ist es entscheidend, so früh wie möglich Feedback zu unseren API-Verträgen zu erhalten. Die APIs von Snyk ermöglichen Nutzern innerhalb und außerhalb von Snyk den Zugriff auf unsere branchenführenden Sicherheitsprodukte. Entwickler verlassen sich auf Snyk und unsere APIs, um ihren SDLC zu unterstützen und sichere Anwendungen zu entwickeln. Hochwertige APIs bereitzustellen, ist entscheidend für den Erfolg unserer Plattform. Ein hochwertiger API-Entwicklungsprozess ist wiederum entscheidend, um Nutzern diese APIs bereitzustellen.

In diesem Blogbeitrag stellen wir einige der Prozesse und Tools vor, mit denen Snyk seine API-first-Plattform entwickelt.

Warum Shift left?

Softwareunternehmen wissen seit Langem, welchen Wert es hat, Tests, Betrieb und Sicherheit nach links zu verlagern. Statt auf spätere Reviews im SDLC zu warten, erhalten Entwickler mithilfe von Techniken wie Continuous Integration und Tools wie den IDE-Plug-ins von Snyk schnell Feedback. Das Ergebnis: schnellere Bereitstellung, eine verbesserte Sicherheitslage, geringere Kosten und insgesamt ein zuverlässigerer Prozess für die Anwendungsbereitstellung. Bei der API-Entwicklung lässt sich derselbe Shift-left-Ansatz anwenden. Am besten erhalten Sie frühzeitig Feedback, idealerweise mithilfe automatisierter Tools.

Styleguides und der Ansatz von Snyk

Die Entwicklung RESTful APIs ist eine besondere Form der Anwendungsentwicklung, die die richtigen Prozesse und Tools erfordert. Die V3-APIs von Snyk sollen Nutzern zuverlässige, konsistente, leicht verständliche und innovative Möglichkeiten bieten, mit der zugrunde liegenden Plattform zu interagieren. Bei Snyk definieren wir unsere APIs mit OpenAPI (auch bekannt als Swagger), dem De-facto-Standard für die Definition von RESTful APIs. Eine API-Spezifikation in einem maschinen- und menschenlesbaren Format allein garantiert jedoch nicht, dass die APIs unseren Anforderungen an die Benutzerfreundlichkeit entsprechen. APIs müssen auf der gesamten Plattform konsistent sein, damit Nutzer problemlos mit den verschiedenen Bereichen der Plattform interagieren können.

Für konsistente APIs brauchen wir Stilstandards. Viele Unternehmen verwenden einen Styleguide, der Content-Erstellern Vorgaben für einen einheitlichen Ton und Schreibstil macht. Snyk hat einen eigenen Styleguide für die API-Entwicklung erstellt: unser API Stylebook für Teams, die APIs entwickeln. Wenn unser Unternehmen wächst und mehr Entwickler APIs erstellen, hilft uns unser API-Stil dabei, für Konsistenz in unseren APIs und ein einheitliches Developer-Erlebnis für unsere Nutzer zu sorgen. Ein Styleguide allein reicht jedoch nicht aus. Wir brauchen außerdem Mechanismen, mit denen Entwickler sicherstellen können, dass sie die Vorgaben einhalten.

Eine Möglichkeit, die Einhaltung der Vorgaben sicherzustellen, sind manuelle Reviews. Da unsere APIs in OpenAPI spezifiziert und in der Versionsverwaltung gepflegt werden, können wir für API-Definitionen denselben Review-Prozess nutzen wie für andere Code-Artefakte. Entwickler können Pull Requests (PRs) für ihre API-Änderungen erstellen und Kollegen um Feedback bitten. Dieses manuelle Vorgehen kann die Einhaltung der Vorgaben wirksam sicherstellen. Wie alle manuellen Prozesse ist es jedoch anfällig für menschliche Fehler und nicht immer zeitnah. Snyk ist ein global verteiltes Unternehmen mit Remote-first-Arbeitsweise. Wenn Sie auf das Review eines API-PRs durch einen Kollegen warten, kann sich die Bearbeitung verzögern und die Produktivität sinken – insbesondere bei Aspekten des Review-Prozesses, die sich automatisieren lassen. Hier hilft unser Ansatz, API-Reviews zu automatisieren und Sicherheitsprüfungen nach links zu verlagern.

Snyk-Entwickler, die APIs erstellen, verfügen über die drei nötigen Voraussetzungen, um Reviews lokal und automatisiert durchzuführen:

• Der Snyk-API-Standard, ausgedrückt als Regelwerk

• Die in OpenAPI geschriebene API

• Linting-Tools, mit denen sich prüfen lässt, ob die vom Entwickler verfasste OpenAPI-Spezifikation den Regeln der Spezifikation entspricht

Mit lokalen Linting-Tools für ihre APIs erhalten Entwickler Echtzeit-Feedback. So können Snyk-Entwickler Probleme mit ihrer API beheben, bevor sie in ein manuelles Review gehen. Der Linter lässt sich außerdem in unsere CI-Jobs integrieren, um die Einhaltung der Vorgaben zu prüfen. Da alle Entwicklungsteams dieselben Regeln verwenden, kann die Snyk-Plattform unseren Nutzern ein konsistenteres API-Erlebnis bieten.

Zusammenarbeit mit Optic

Nachdem wir entschieden hatten, unser Datenmodell mit REST abzubilden, begannen wir, unseren API-Standard mit JSON API zu definieren. Sobald ein erster Entwurf des Standards vorlag, wollten wir ihn ausführbar machen – als Standard-as-Code, damit Entwicklungsteams nicht durch ein „Experten-API-Review“ ausgebremst werden. Im Sinne unseres Shift-left-Ansatzes wollten wir schnelles Feedback ermöglichen.

Die ersten Tools, die wir für die Erstellung dieser Regeln fanden, eigneten sich hervorragend für die syntaktische Prüfung durch Musterabgleich, etwa für das Linting auf gültiges OpenAPI 3. Doch bei der Umsetzung unserer API-Standards stießen wir schnell an die Grenzen dieses Ansatzes. Solche Regeln sind mühsam zu lesen und zu schreiben (JSONPath und Regex) und können nur Bedingungen für den Inhalt der gerade geprüften API-Spezifikationsversion festlegen. Wir kamen zu dem Schluss, dass wir eine robustere Lösung brauchten, und fanden in Optic eine passende Option.

Optic ist ein Partner, der in seinen API-Review- und Governance-Produkten Sicherheitsprüfungen nach links verlagern möchte und API-design-first-Workflows unterstützt. Das Ergebnis unserer Zusammenarbeit mit Optic in diesem Bereich ist Optic CI, ein API-Linting-Produkt, mit dem sich unsere API-Standards ausdrücken lassen. Optic-CI-Regeln sind als High-Level-Typescript-DSL leicht zu lesen und zu schreiben. Vor allem berücksichtigt Optic CI dieselbe Realität der API-Entwicklung, die auch Snyk kennt: APIs verändern und entwickeln sich ständig weiter. Die Regeln beziehen sich auf Änderungen an einer API statt auf einen einzelnen Zeitpunkt. Dadurch sind sie flexibel genug, um kontinuierliche Verbesserungen und Verfeinerungen unserer APIs voranzutreiben und diese Änderungen zu steuern, ohne dass sich ein Berg von „Lint-Ausnahmen“ ansammelt, während die Standards selbst weiterentwickelt werden.

Weitere Neuigkeiten folgen

Snyk setzt sich für eine Plattform ein, bei der Entwickler und APIs im Mittelpunkt stehen. Indem wir Sicherheitsprüfungen in unserem API-Entwicklungs-SDLC nach links verlagern, geben wir unseren Entwicklern frühzeitig Feedback. Bleiben Sie dran für unseren nächsten Beitrag zum API-Entwicklungsprozess von Snyk. Darin erfahren Sie, wie wir Tools einsetzen, um Versionen unserer API zu verwalten.

Möchten Sie Teil des Teams werden, das die Snyk-Plattform entwickelt? Sehen Sie sich unsere offenen Stellen im Engineering an und unterstützen Sie uns bei unserer Mission für Entwicklersicherheit.