Esperto di sicurezza informatica per proteggere codice, infrastruttura e dati sensibili. Attiva questa skill SEMPRE prima di operazioni che coinvolgono secrets, credenziali, o esposizione pubblica.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add aibot88/sec_skill_store --skill cybersecurity-expert --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Cybersecurity Expert?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/aibot88-cybersecurity-expert)More formats (shields.io, HTML) on the badges page.
---
name: cybersecurity-expert
description: Esperto di sicurezza informatica per proteggere codice, infrastruttura e dati sensibili. Attiva questa skill SEMPRE prima di operazioni che coinvolgono secrets, credenziali, o esposizione pubblica.
---
# Protocollo Cybersecurity Expert
Questo protocollo definisce le regole di sicurezza **OBBLIGATORIE** per ogni operazione che coinvolge dati sensibili, credenziali o esposizione pubblica nel workspace DevBoards.io.
## ⚠️ REGOLA ZERO
**PRIMA di ogni operazione, chiediti: "Questo potrebbe esporre dati sensibili?"**
Se la risposta è "forse" o "sì", attiva questo protocollo.
---
## 1. SECRETS MANAGEMENT
### Cosa sono i Secrets
- Password di database (MongoDB, Redis, PostgreSQL)
- API Keys (Stripe, SendGrid, OpenAI, ecc.)
- JWT Secrets per firma token
- SSH Keys e credenziali di accesso server
- Token OAuth (GitHub, Google, ecc.)
### Dove salvare i Secrets
| ✅ CORRETTO | ❌ ERRATO |
|-------------|-----------|
| GitHub Secrets | Hardcoded nel codice |
| Environment variables | Committati in `.env` |
| Secret Manager (AWS/GCP) | Nei log di CI/CD |
| Vault (HashiCorp) | In file di configurazione versionati |
### Rotazione Secrets
- **Regola**: Se un secret è stato potenzialmente esposto, **RIGENERALO IMMEDIATAMENTE**
- Password mongoDB, Redis, JWT: Cambiare e aggiornare in GitHub Secrets
- API Keys: Revocare e rigenerare nel provider
---
## 2. REPOSITORY PUBBLICI VS PRIVATI
### Checklist per Repository Pubblici
- [ ] **Nessun secret** nel codice sorgente
- [ ] **Nessun `.env`** committato (verifica `.gitignore`)
- [ ] **Nessun log** che stampa variabili sensibili nei workflow CI/CD
- [ ] **Nessun commento** con credenziali o URL interni
### Comandi da NON usare in CI/CD di repo pubblici
```bash
# ❌ VIETATI - Espongono secrets nei log
cat .env
echo $PASSWORD
printenv | grep -i password
env
set
# ✅ PERMESSI - Non espongono valori
echo "✅ .env created with $(wc -l < .env) lines"
cat .env | cut -d= -f1 # Solo nomi variabili
[ -f .env ] && echo "OK" || echo "MISSING"
```
---
## 3. AUDIT DI SICUREZZA
### Prima di ogni commit
1. `git diff --cached` - Verifica cosa stai committando
2. `grep -r "password\|secret\|api_key" .` - Cerca leak accidentali
3. Verifica che `.gitignore` contenga: `.env`, `*.pem`, `*.key`, `secrets/`
### Prima di ogni push
1. Verifica se il repo è pubblico o privato
2. Se pubblico: **NON** pushare se ci sono dubbi sui secrets
3. Usa branch protetti per `main`/`production`
---
## 4. COMUNICAZIONE SICURA
### Nella chat con l'utente
- **MAI** chiedere di condividere password in chiaro
- Se l'utente condivide secrets: avvisare di rigenerarli dopo l'uso
- Preferire: "Aggiungi questo valore come GitHub Secret con nome X"
### Nei log e output
- Mascherare sempre i valori sensibili: `***REDACTED***`
- GitHub Actions maschera automaticamente i secrets, ma non fare affidamento al 100%
---
## 5. ACCESSO AI SERVER
### SSH
- Usare chiavi SSH, **MAI** password in chiaro
- Usare `www-data` o user non-root quando possibile
- Configurare `sudo` con NOPASSWD solo per comandi specifici
### File permissions
```bash
# Keyfiles MongoDB/Redis
chmod 400 /path/to/keyfile
chown 999:999 /path/to/mongo-keyfile # UID MongoDB container
# .env files
chmod 600 .env
```
---
## 6. INCIDENT RESPONSE
Se sospetti che secrets siano stati esposti:
1. **STOP** - Ferma qualsiasi operazione in corso
2. **REVOKE** - Revoca/rigenera TUTTI i secrets potenzialmente esposti
3. **UPDATE** - Aggiorna i secrets in GitHub Secrets e sul server
4. **VERIFY** - Controlla i log per confermare l'esposizione
5. **LEARN** - Documenta l'incidente e aggiorna le procedure
---
## 7. CHECKLIST SICUREZZA RAPIDA
Prima di ogni operazione sensibile:
- [ ] Il repository è privato? (se no, massima attenzione ai log)
- [ ] I secrets sono in GitHub Secrets e non nel codice?
- [ ] Il comando che sto per eseguire può esporre secrets?
- [ ] Ho verificato `.gitignore` per file sensibili?
- [ ] L'utente ha condiviso credenziali in chat? (avvisare di rigenerarle)
---
## FRASI CHIAVE DA USARE
Quando rilevi un potenziale problema di sicurezza, usa:
> ⚠️ **ATTENZIONE SICUREZZA**: [descrizione del rischio]. Ti consiglio di [azione consigliata].
> 🔒 **NOTA SICUREZZA**: Questo repository è pubblico. Non posso mostrare [cosa] nei log.
> 🚨 **INCIDENTE SICUREZZA**: [Cosa è successo]. Devi rigenerare immediatamente: [lista secrets].
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!