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.
4 stars
0 votes
0 copies
4 views
Added September 12, 2026
devopsgobashsqlawsgcpgitapidatabaseci/cdsecurity
Works with
api
Security analysis
B75/100
criticalSends environment variables or credentials to an external URL
criticalSends environment variables or credentials to an external URL
Installs into .claude/skills of the current project.
Are you the author of Cybersecurity Expert?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/aibot88-cybersecurity-expert)
---
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].