GitSecOps

Software-Lieferketten nachvollziehbar und belastbar machen. Sicherheit und Nachweise für CI/CD-Pipelines. Betrieben von MHM Digitale Lösungen UG.

[GitSecOps @gitsecops]

@omeke_NC Same pattern one layer up: an SBOM confirms log4j-core is present, not whether the vulnerable class path is ever reached. VEX plus reachability analysis turns presence into exploitability.

[GitSecOps @gitsecops]

@JacksonWes Genau das löst den Drift-Fall: ändert sich das Tool, verfällt die Admission, die Anfrage geht in die Freigabe-Warteschlange. Granularität interessiert mich: pro Tool-Hash oder pro Capability-Klasse? Und was passiert bei einer Demotion mitten im Run?

[GitSecOps @gitsecops]

tfsec und checkov prüfen gegen einen festen Katalog bekannter Fehler. Eigene Regeln wie Instanztyp-Verbote stehen da nicht drin. OPA/Conftest schließt die Lücke: Rego-Policies gegen den terraform plan JSON-Output, geprüft zwischen plan und apply.https://t.co/B3nYUC499m

[GitSecOps @gitsecops]

Ein gestohlener NPM_TOKEN in eurer CI bleibt gültig, bis ihr ihn widerruft. npm Trusted Publishing ersetzt ihn durch OIDC: kurzlebig, pro Lauf, nicht wiederverwendbar. Läuft auf GitHub Actions, GitLab CI, CircleCI, nicht auf selbst gehosteten Runnern.https://t.co/sE9DzUPe1D

[GitSecOps @gitsecops]

Deine SECURITY.md ist laut GitHub-Doku kein Meldeweg, nur eine Anleitung als Textdatei: kein Formular, keine Benachrichtigung, kein Status. Private Vulnerability Reporting ist davon unabhängig und der tatsächliche Meldeweg im Security-Tab. https://t.co/pAUA9QyLzs

[GitSecOps @gitsecops]

@Dayhaysoos @poteto Good instinct. Since the agent would help shape those pattern rules over time, the rule set itself needs a separate human review gate, like any critical config, so the agent can't quietly drift around rules it helped write.

[GitSecOps @gitsecops]

@RikerTrek Not sure it's replacement. SAST's value is its rigidity: same code, same rules, same alerts every run. That makes it auditable for compliance and alert history. Agents with more context will vary run to run. Different job: a context/prioritization layer on top, not a swap.

[GitSecOps @gitsecops]

CodeQL Default Setup aktiviert Code Scanning ohne eigene Workflow-Datei. Ein leerer Alert-Bereich heißt dort nur: Die Abfragen haben nichts gemeldet; nicht, dass dein Code sicher ist. https://t.co/qsSy5YJslI

[GitSecOps @gitsecops]

GitHub Attestations und cosign signieren beide über Sigstore. Entscheidend ist, wer die Vertrauensinfrastruktur betreibt und wer am Ende prüft. Für private Repositories braucht es laut Doku GitHub Enterprise Cloud, nicht Free, Pro oder Team. https://t.co/GB1HEZRdmj

[GitSecOps @gitsecops]

GitHub Immutable Releases sperrt Git-Tag und Release-Assets nach dem Veröffentlichen. Geschützt ist nur das veröffentlichte Release selbst, nicht was vorher im Build passiert ist. Der automatische Quellcode-Zip ist laut Doku davon ausgenommen. https://t.co/RGfpd52t6i

[GitSecOps @gitsecops]

Security Champions werden nominiert, nicht zugewiesen. Ohne rund 20% freigegebene Zeit bleibt das Programm ein Wunsch, dann gewinnt „keine Zeit für Security“ bei der nächsten Deadline.
https://t.co/CoHbPP9c6u

[GitSecOps @gitsecops]

Ein Lock-File pinnt Provider, nicht Module. Module mit Bereichs-Constraint holen bei jedem Neuaufbau die neueste passende Version, ungetrackt. Ohne ?ref= zieht Terraform den Standard-Branch. Ein Tag lässt sich verschieben, ein Commit-SHA nicht.
https://t.co/dWfV1jGJNM

.

[GitSecOps @gitsecops]

Eine SBOM vom Lieferanten bekommen heißt nicht, dass du etwas in der Hand hast. Vier Checks vor dem Ablegen: maschinenlesbar statt PDF, sieben NTIA-Pflichtfelder, Version abgleichen, Tiefe einordnen. Geprüft ist nur: auswertbar, nicht korrekt.
https://t.co/LFDIj0YEhn
.

[GitSecOps @gitsecops]

@PrateekJainDev OIDC removes static AWS keys, but trust shifts to the sub claim condition in the IAM trust policy. If that condition is scoped only to the repo, any branch or PR workflow there can assume the same role. AWS recommends repo:org/repo:ref:refs/heads/branch over repo:org/repo.

[GitSecOps @gitsecops]

@unit0r Same lever in CI/CD: a workflow step with ambient runner credentials (cloud metadata endpoint, service account token) gets the same lateral movement path as the HF worker. Enforcement means least-privilege OIDC: audience/subject claim binding, not trust in the workflow author.

[GitSecOps @gitsecops]

GitHub-2FA-Pflicht in der Org schützt nur die Anmeldung am GitHub.com-Konto. Ein Bot-Konto mit aktivierter 2FA authentifiziert sich in Automatisierungen unverändert über sein bestehendes Token, SSH-Keys ebenso unangetastet.https://t.co/tmzkCdNUUO

[GitSecOps @gitsecops]

@juliobmelo Good breakdown. It also shows why GitHub's own hardening guidance matters: pinning actions to a full commit SHA instead of a version tag would have kept workflows on the original clean commit even after the tag got reactivated. Tags are mutable, SHAs aren't.

[GitSecOps @gitsecops]

16.500 automatisierte Zugriffe auf UNCTADstat (April bis Juni 2026), wahrscheinlich, aber unbestätigt, OpenAI-Agenten zugeordnet. Wo der direkte Weg blockiert war, versuchten die Agenten aktiv Umgehungen. Fazit: Allowlisting statt Blockieren.https://t.co/NmWEKYhSAl

[GitSecOps @gitsecops]

Bei IMDSv1 reicht ein GET aus einer SSRF-Lücke, um EC2-Credentials abzugreifen, ganz ohne Token. IMDSv2 verlangt vorher ein PUT mit eigener Token-Anfrage, das eine reine GET-SSRF-Lücke nicht auslösen kann.https://t.co/7n5vGGzuAM