Um scanner de segurança CI/CD dedicado. Análise estática aos ficheiros de workflow no teu repo: injeção de workflow, actions sem pinning, tokens com privilégios a mais, drift OIDC. Apanhado antes de qualquer runner pegar no job.
Os nossos scanners fazem parse das tuas configs de pipeline numa AST e num grafo de dataflow, depois correm packs de regras proprietárias informados pelo OpenSSF Secure Workflows, pelos playbooks da StepSecurity e pela nossa própria investigação sobre incidentes reais de envenenamento. As descobertas fluem para o dashboard unificado ao lado de SAST, SCA, IaC, Secrets e Container.
Sempre que interpolas ${{ github.event.* }}, nomes de branch, títulos de PR ou corpos de issue num bloco `run:`, estás a fazer shell-injection à tua própria pipeline. O scanner faz taint a cada input não confiável e segue-o por cada passo até aterrar numa shell, mesmo através de composite actions.
@v3, @main, @latest, cada ref flutuante é um incidente futuro de supply chain. O scanner assinala cada action que não esteja fixada num SHA completo, cada action de um publicador não verificado, e faz cruzamento contra o feed de actions maliciosas.
Os scopes default do GITHUB_TOKEN são `write` para quase tudo. Detetamos `permissions:` por definir, scopes amplos que não usas, e recomendamos o conjunto mínimo por job.
Identidade federada AWS, Azure e GCP a partir de GitHub, GitLab e CircleCI. Apanhamos padrões `sub` demasiado amplos, verificações de audience em falta e políticas de trust que qualquer fork pode assumir.
`echo $SECRET`, secrets passados como args posicionais, secrets registados em artefactos, secrets cozidos em camadas de container. Detetados estaticamente, antes de o runner emitir uma única linha.
PRs não confiáveis a escrever em caches que branches protegidas leem. Reutilização de runner self-hosted sem isolamento. Uploads de artefacto de contextos não confiáveis. A classe toda dos CVEs de cache-poisoning pós-2024.
A maioria dos incidentes de pipeline é visível no YAML. Lemo-lo como o atacante o lê, estaticamente, com contexto de dataflow completo, para a descoberta aterrar na revisão da PR, não num retro pós-incidente.
Os ficheiros de workflow têm o mesmo escrutínio que o teu código de aplicação: parsing AST, propagação de taint, análise source-to-sink. O modelo de ameaças é específico de pipelines: triggers não confiáveis, fontes de action, scopes de token, trust OIDC, isolamento de runner.
Parsers de primeira classe para os dialetos CI que entregam a maioria das pipelines hoje, incluindo workflows reutilizáveis, cadeias `include:` do GitLab e Jenkinsfile (Groovy declarativo e scripted). Novos dialetos a pedido.
Cada descoberta chega como comentário inline na linha YAML problemática, a mesma superfície que o SAST. Sem dashboard novo para aprender, sem fila de triagem separada, sem passo de runner privilegiado para instalar.
Liga o GitHub ou o GitLab. Os nossos scanners puxam os ficheiros de pipeline e correm em cada push (ou a pedido). Sem nada para instalar no teu CI, sem passo de runner privilegiado. As descobertas fluem para o dashboard unificado e para a tua revisão de PR.
Ver todas as integraçõesCerto. Liga o repo uma vez. Os nossos scanners leem .github/workflows, .gitlab-ci.yml, Jenkinsfile e o resto diretamente, depois reportam descobertas como comentários inline na linha problemática e no dashboard unificado. Sem passo para adicionar à tua pipeline, sem runner privilegiado para instalar.
Workflows do GitHub Actions (incluindo composite e reutilizáveis), YAML do GitLab CI (incluindo cadeias `include:`) e Jenkinsfile (Groovy declarativo e scripted). As definições de action (action.yml mais wrappers Dockerfile-action) também são lidas, por isso fluxos de taint cross-action são rastreados. Outros dialetos são acrescentados a pedido do cliente.
Não precisamos do payload. Fazemos taint a todos os valores que vêm de `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, refs de branch e tag de um fork, e seguimo-los por `env:`, `with:`, valores de output e fronteiras de composite-action. Se o valor tainted chega a um bloco `run:`, um `eval` em JavaScript actions ou um comando substituído por shell, isso é uma descoberta, independentemente de já teres sido explorado ou não.
Sim. Cada entrada `uses:` é cruzada com o feed de actions maliciosas do OpenSSF, a lista de publicadores verificados e as nossas próprias heurísticas de typo-squat em nomes de actions. Tags sem pinning assinalam-se à parte, porque mesmo uma action legítima se torna risco de supply chain se não a fixares num SHA.
Tudo o que corresponde aos padrões de entropia e provider do nosso pack de regras de Secret Detection é assinalado também em ficheiros CI/CD. Detetamos ainda secrets passados como args posicionais de CLI (visíveis no `ps`), secrets registados via `echo` e secrets cozidos em inputs de workflows reutilizáveis. As descobertas deduplicam com o scanner de secrets para não ficares com elas duas vezes.
Sim. Fazemos parse a diretivas `runs-on:`, detetamos runners com estado de filesystem partilhado entre PRs não confiáveis, assinalamos guardas tipo `actions/cleanup` em falta, e avisamos sobre jobs que escalam a root ou montam o socket Docker.
Sem cartão de crédito. Sem chamada de setup. Escolhe o agente, cola o comando e o Cybe aplica as tuas regras a partir do próximo prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP alojado, sem instalação. Basta registar o URL no teu agente.