Sicherheit bei SecureCodingHub
Wir entwickeln Security-Schulungssoftware. Wir nehmen unsere eigene Sicherheit ernst. So schützen wir Ihre Daten und unsere Infrastruktur.
SecureCodingHub wird von LimePlate, Inc. betrieben. Als Unternehmen, das Entwicklern beibringt, sicheren Code zu schreiben, halten wir uns selbst an höchste Sicherheitsstandards. Unsere Plattform basiert auf einer Security-First-Architektur, und unsere Praktiken werden kontinuierlich überprüft und verbessert.
Infrastruktursicherheit
Alle ruhenden Daten werden mit AES-256-Verschlüsselung verschlüsselt. Datenbank-Volumes, Backups und Dateispeicher sind alle mit Schlüsseln verschlüsselt, die über einen dedizierten Key-Management-Service verwaltet werden.
Die gesamte Kommunikation zwischen Clients und unseren Servern verwendet TLS 1.3. Wir setzen HTTPS an allen Endpoints mit HSTS-Headern und Certificate-Transparency-Monitoring durch.
Kundendaten werden auf der Anwendungsebene logisch isoliert. Die Daten jeder Organisation werden mit strikten Zugriffskontrollen getrennt, sodass kein Datenaustausch zwischen Mandanten möglich ist.
Authentifizierung und Zugriff
Enterprise-Kunden können ihren Identity-Provider per SAML 2.0 Single Sign-On integrieren. Wir unterstützen alle wichtigen IdPs, einschließlich Azure AD, Okta und OneLogin.
MFA-Unterstützung fügt Benutzerkonten eine zusätzliche Sicherheitsebene hinzu. Wir unterstützen TOTP-basierte Authenticator-Apps für die Zweitfaktor-Verifizierung.
Sitzungen sind kryptografisch mit kurzlebigen Tokens, automatischer Ablaufsteuerung und Widerrufsmöglichkeiten gesichert. Inaktive Sitzungen werden nach einem konfigurierbaren Timeout beendet.
Compliance
SOC 2 Type II
Wir streben aktiv die SOC 2 Type II-Zertifizierung an. Unsere Kontrollen für Sicherheit, Verfügbarkeit und Vertraulichkeit sind darauf ausgelegt, die Trust Services Criteria zu erfüllen.
GDPR
Wir halten die EU-Datenschutz-Grundverordnung (DSGVO) ein. Wir stellen Auftragsverarbeitungsverträge bereit, unterstützen die Rechte betroffener Personen und führen eine rechtmäßige Grundlage für die Verarbeitung.
CCPA
Wir halten den California Consumer Privacy Act (CCPA) ein. Einwohner Kaliforniens können ihre Rechte auf Auskunft, Löschung und Widerspruch gegen den Verkauf personenbezogener Daten ausüben.
Schwachstellenmanagement
Wir führen regelmäßig Penetrationstests unserer Infrastruktur und Anwendung durch externe Dritte durch. Befunde werden nach Schweregrad triagiert, priorisiert und behoben.
Unsere CI/CD-Pipeline umfasst automatisiertes Dependency-Scanning und Software Composition Analysis. Bekannte Schwachstellen in Drittanbieter-Bibliotheken werden gekennzeichnet und zeitnah behoben.
Wir unterhalten ein Responsible-Disclosure-Programm für Security-Forscher. Wenn Sie eine Schwachstelle entdecken, melden Sie diese bitte an uns, und wir werden gemeinsam mit Ihnen an einer Lösung arbeiten.
Datenverarbeitung
Wir erheben nur die Daten, die zur Erbringung unserer Dienste erforderlich sind. Wir erheben keine unnötigen personenbezogenen Informationen und verkaufen keine Nutzerdaten an Dritte.
Daten werden nur so lange aufbewahrt, wie sie für die Zwecke, für die sie erhoben wurden, benötigt werden. Wenn Daten nicht mehr erforderlich sind, werden sie sicher gelöscht oder anonymisiert.
Nutzer können jederzeit die Löschung ihres Kontos und der damit verbundenen Daten anfordern. Wir bearbeiten Löschanfragen zeitnah und bestätigen den Abschluss innerhalb von 30 Tagen.
Responsible Disclosure
Wir schätzen die Arbeit von Security-Forschern, die dazu beitragen, unsere Plattform und unsere Nutzer sicher zu halten. Wenn Sie glauben, eine Sicherheitslücke in SecureCodingHub entdeckt zu haben, ermutigen wir Sie, diese verantwortungsvoll zu melden.
Richtlinien
- Stellen Sie eine detaillierte Beschreibung der Schwachstelle und Schritte zur Reproduktion bereit
- Räumen Sie uns angemessene Zeit ein, das Problem zu untersuchen und zu beheben, bevor Sie es öffentlich machen
- Greifen Sie während Ihrer Untersuchung nicht auf Daten anderer Nutzer zu, ändern oder löschen Sie diese nicht
- Führen Sie keine Denial-of-Service-Tests oder Social-Engineering-Angriffe durch
Operative Sicherheitspraktiken
Jede Änderung an der Produktion durchläuft ein Pull-Request-Review mit mindestens einem Engineer außerhalb des unmittelbaren Arbeitspaares des Autors. CI führt bei jedem Push Unit-, Integrations- und Sicherheitsprüfungen aus. Produktions-Deployments durchlaufen einen separaten Genehmigungsschritt. Notfalländerungen folgen einem dokumentierten Break-Glass-Verfahren mit retrospektivem Review in derselben Woche. Infrastrukturänderungen werden als Code verwaltet und unter demselben Workflow wie Anwendungscode überprüft.
Software Composition Analysis läuft bei jedem Pull Request und zusätzlich nach einem nächtlichen Zeitplan gegen den Main-Branch. Kritische und hochgradig schwere Advisories lösen eine Benachrichtigung an den On-Call-Engineer mit einem Ziel-Behebungsfenster aus, das in Tagen, nicht Wochen gemessen wird. Advisories mit mittlerem und niedrigem Schweregrad werden in einem wöchentlichen Review gebündelt. Container-Base-Images werden in einem festen Rhythmus neu erstellt, damit transitive Betriebssystem-Patches die Produktion erreichen, ohne dass Anwendungsänderungen erforderlich sind.
Der Incident-Response-Plan definiert vier Schweregradstufen, Eskalationspfade und einen einzigen Verantwortlichen pro Vorfall. Der Ersthelfer ist für die Eindämmung und Kundenkommunikation zuständig, während ein dedizierter Ermittler die technische Spur verfolgt. Post-Incident-Reviews werden ohne Schuldzuweisungen durchgeführt und erzeugen einen schriftlichen Bericht mit Aktionspunkten, die bis zum Abschluss nachverfolgt werden. Der Plan wird mindestens zweimal im Jahr anhand vorgegebener Szenarien geübt, damit das Muskelgedächtnis bereits vor einem realen Vorfall vorhanden ist.
Was wir von Kunden erwarten
Wenn Ihr Security-Team während eines vertraglich vereinbarten Pentests, einer internen Überprüfung oder der routinemäßigen Nutzung des Produkts etwas entdeckt, melden Sie es direkt unserem Security-Team, anstatt es zunächst öffentlich zu diskutieren. Wir bestätigen den Eingang innerhalb von zwei Werktagen, teilen Ihnen eine Tracking-Kennung mit und liefern Statusupdates, bis das Problem geschlossen ist. Wir betrachten koordinierte Offenlegung als Partnerschaft.
Kunden-Administratoren steuern die Rollenzuweisung innerhalb ihres Mandanten. Das von uns empfohlene Prinzip ist dasselbe, das wir intern anwenden: Weisen Sie die engste Rolle zu, mit der ein Benutzer seine Arbeit erledigen kann, und überprüfen Sie die Zuweisungen in einem regelmäßigen Zyklus. Insbesondere administrativer Zugriff sollte auf eine kleine, namentlich benannte Gruppe beschränkt sein, und diese Gruppe sollte auditiert werden, wenn Personen ihre Rolle in Ihrer Organisation wechseln.
Wenn eine Person Ihre Organisation verlässt, sollte ihre Deaktivierung in Ihrem Identity-Provider über SCIM weitergegeben werden, um den Zugriff auf die Plattform zu entfernen. Wir empfehlen für jede Organisation mit mehr als dreißig Lizenzen dringend SCIM-basierte Bereitstellung statt manueller Benutzerverwaltung. Wenn Sie SCIM heute nicht einführen können, ist eine Off-Boarding-Checkliste auf Kontoebene mit einem benannten Verantwortlichen die nächstbeste Kontrolle.
Was wir veröffentlichen und was nicht
Eine Statusseite, die die Plattformverfügbarkeit und Vorfälle mit eingeschränkter Servicequalität abdeckt. Eine Liste der Sub-Auftragsverarbeiter. Den aktuellen Auftragsverarbeitungszusatz (DPA). Diese Sicherheitsseite selbst. Sobald SOC 2 Type II abgeschlossen ist, ist der Bericht unter NDA auf Anfrage über Ihren Account-Ansprechpartner verfügbar. Wesentliche Richtlinien-Updates, die Kunden betreffen, werden über Ihren Account-Ansprechpartner angekündigt und nicht in einem Changelog versteckt.
Interne Netzwerkarchitekturdiagramme, detaillierte Authentifizierungsflüsse, das spezifische Tooling, das unser Security-Team verwendet, Schlüsselrotationspläne auf Ebene einzelner Schlüssel sowie die Namen und Rollen der Mitarbeiter im Security-Team. All dies kann unter NDA überprüft werden, wenn das Gespräch es erfordert – beispielsweise während eines beschaffungsgeleiteten Security-Reviews – aber sie gehören nicht auf eine öffentliche Seite. Eine Veröffentlichung würde die Kosten eines gezielten Angriffs senken, ohne einem Kunden einen echten Mehrwert zu bieten.
Sicherheit bei SecureCodingHub: häufig gestellte Fragen
Wie unsere eigene Aufstellung sich mit den Richtlinien und Compliance-Fragen abbildet, die Kunden während der Beschaffung am häufigsten stellen.
Wo liegt die Application-Security-Richtlinie von SecureCodingHub?
Unsere Application-Security-Richtlinie wird primär über die auf dieser Seite beschriebenen Engineering-Praktiken durchgesetzt und nicht als separates Marketing-Artefakt. Jede Änderung an der Produktion durchläuft ein Pull-Request-Review und eine CI-Pipeline, die Unit-, Integrations- und Sicherheitsprüfungen ausführt. Dependency-Scanning läuft bei jedem Pull Request und zusätzlich nächtlich gegen den Main-Branch. Die Application-Security-Richtlinie, nach der Ihr Beschaffungsteam wahrscheinlich fragt, befindet sich im SOC 2 Type II-Paket, an dem wir arbeiten, und kann auf Anfrage unter NDA geteilt werden.
Wie geht SecureCodingHub mit Information-Security-Compliance um?
Information-Security-Compliance ist hier auf Produktebene verankert und kein Theater. Wir streben aktiv SOC 2 Type II mit Kontrollen an, die auf die Trust Services Criteria für Sicherheit, Verfügbarkeit und Vertraulichkeit ausgelegt sind. Wir arbeiten bereits im Einklang mit DSGVO und CCPA, unterstützen Auftragsverarbeitungsverträge und respektieren die Rechte betroffener Personen. Die Compliance-Aufstellung, die Sie heute verifizieren können, ist auf dieser Seite und im Auftragsverarbeitungszusatz dokumentiert; der SOC 2-Bericht selbst wird nach Abschluss des Audits unter NDA über Ihren Account-Ansprechpartner verfügbar sein.
Veröffentlichen Sie Ihre vollständige Information-Security-Richtlinie?
Wir veröffentlichen, was Kunden hilft, fundierte Entscheidungen zu treffen, und halten bewusst zurück, was die Kosten eines gezielten Angriffs senken würde. Das Material zur Information-Security-Richtlinie, das öffentlich ist, umfasst diese Sicherheitsseite, die Statusseite, die Liste der Sub-Auftragsverarbeiter und den aktuellen Auftragsverarbeitungszusatz. Interne Netzwerkarchitektur, detaillierte Authentifizierungsflüsse, Schlüsselrotationspläne und die personelle Besetzung des Security-Teams werden unter NDA während beschaffungsgeleiteter Security-Reviews überprüft und nicht auf einer öffentlichen Seite veröffentlicht.
Wie sieht die Data-Security-Richtlinie von SecureCodingHub in der Praxis aus?
Unsere Data-Security-Richtlinie basiert standardmäßig auf minimaler Datenerhebung und ist nach dem Prinzip der geringsten Berechtigungen konzipiert. Ruhende Daten werden mit AES-256 unter Verwendung von Schlüsseln verschlüsselt, die über einen dedizierten Key-Management-Service verwaltet werden, und Daten in der Übertragung verwenden TLS 1.3 mit erzwungenem HSTS. Kundendaten werden auf der Anwendungsebene logisch isoliert, sodass kein mandantenübergreifender Datenaustausch möglich ist. Wir bewahren Daten nur so lange auf, wie es nötig ist, unterstützen nutzerinitiierte Löschung innerhalb von 30 Tagen und verkaufen niemals Nutzerdaten an Dritte.
Fragen zu unserer Sicherheit?
Wenn Sie Fragen zu unseren Sicherheitspraktiken haben, eine Kopie unserer Sicherheitsdokumentation benötigen oder Compliance-Anforderungen besprechen möchten, wenden Sie sich an unser Security-Team.
security@securecodinghub.com