メニュー
Ensures information security and compliance with French security standards
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Guide users through creating custom VS Code agents with specialized capabilities, tool restrictions, and subagent workflows. Use when users want to create agent modes, define specialized workflows with context isolation, or build multi-stage agent systems with different tool access per stage. Provides structured interview process for comprehensive agent development.
Technology-agnostic, referential-agnostic orchestration framework for all compliance standards (RGAA, RGESN, RGS, RGPD, RGI, W3C-WSG)
Ensures digital accessibility for all users (WCAG 2.1 AA compliance, French RGAA 4.1.2 standard)
Ensures eco-responsible IT practices and minimizes environmental impact
Ensures system interoperability via open standards, documented APIs, and standardized data exchange
Ensures personal data protection and privacy rights according to GDPR/RGPD
| name | compliance-rgs |
| description | Ensures information security and compliance with French security standards |
| category | Security & Governance |
| keywords | RGS, security, encryption, authentication, authorization, incident response, vulnerability management, ANSSI, French security framework |
| license | MIT |
Règles de Gouvernance de Sécurité (Rules for Security Governance) — Official French Government Security Framework
The RGS framework is built on 5 security domains:
Purpose: Identify which RGS phases are applicable to your specific project
1. What is the primary architecture type?
2. What type of data does it handle?
3. Who accesses this system?
4. What is the required security level?
Based on your project type, find which phases are critical (⭐⭐⭐) and important (⭐⭐).
Then jump to: "Phase Navigation Index" → "RGS Implementation Phases"
⚠️ Critical Prerequisite: Make sure you've reviewed the project architecture at:
copilot-instructions.md — Architecture overviewdocs/compliance/RGS-IMPLEMENTATION.md — project-specific patterns| Project Type | Phase 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 | Phase 6 | Phase 7 | Phase 8 |
|---|---|---|---|---|---|---|---|---|
| Web App | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| REST API | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| Microservice | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| Background Job | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| CLI Tool | ⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐ | ⭐ |
| Infrastructure | ⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
Legend: ⭐⭐⭐ = Critical | ⭐⭐ = Important | ⭐ = Secondary
Organizations must follow a structured 5-step approach to achieve RGS compliance:
Agent Workflow: Identify your project type from quick start above → Select applicable phases → Work through checklists → Reference detailed annex files
| Phase | Focus Area | Applicable To | Key Deliverable |
|---|---|---|---|
| Phase 1 | Risk Management | All projects | Risk assessment report |
| Phase 2 | Authentication & Authorization | All user-facing systems | Auth architecture |
| Phase 3 | Encryption & Cryptography | All projects handling data | Crypto/TLS configuration |
| Phase 4 | Input Validation & Attack Prevention | Web apps, APIs | Validation rules |
| Phase 5 | Audit Logging & Monitoring | All production systems | Log strategy |
| Phase 6 | Vulnerability Management & Patch | All projects | Patch policy |
| Phase 7 | Third-Party Risk Management | Projects with integrations | Vendor assessment |
| Phase 8 | Incident Response & Continuity | All production systems | IR procedure |
Focus Area: Foundational - Required for ALL projects
Why This Matters: Without risk analysis, you don't know what you're protecting or why
Quick Assessment: Do you have a documented risk register? Have threats been identified?
Focus Area: Critical for Web Apps, APIs, Microservices (⭐⭐⭐)
Why This Matters: This is where users prove they are who they claim to be. Failures here = all other protections useless
Quick Assessment: Can an unauthenticated user access any protected resource? Are passwords stored in plain text?
Focus: Verify entity identity and control access per RGS security levels
Cryptographic Authentication Protocol (Machine-to-Machine):
Security Level Selection (Choose one per use case):
Person Unlock Mechanism (How user proves identity):
Authentication Credentials Protection:
Session Lifecycle:
Multi-Factor Authentication (For Level , *):
Certificate-Based Authentication (If implementing digital certificates):
Brute Force & Attack Protection:
Audit & Logging:
Session State Management:
Trusted Infrastructure (If using third-party auth):
📌 Reference Documentation: See RGS-ANNEX-B3-DETAILED.md for authentication models, machine-to-machine protocols, person unlock mechanisms, session lifecycle, third-party trust, and comprehensive audit requirements.
### Phase 3: Encryption & Cryptography (RGS Chapter 3)
**Focus Area**: Critical for ALL projects (⭐⭐⭐)
**Why This Matters**: Encryption is the only thing that stops attackers from reading your data even if they breach you
**Quick Assessment**: Is all traffic using TLS 1.3? Are database passwords encrypted at rest? **See [RGS-ANNEX-B2-DETAILED.md](./RGS-ANNEX-B2-DETAILED.md)**
**Focus**: Protect data in transit and at rest per RGS Annex B2 requirements
#### Actionable Requirements
- [ ] **TLS 1.3+** for all communications (TLS 1.2 minimum with strong ciphers)
- Perfect Forward Secrecy (PFS) via ECDHE
- HSTS header: `max-age=31536000; includeSubDomains`
- [ ] **Approved Algorithms** (RGS Annex B2):
- Symmetric: **AES-256** (preferred), AES-192, AES-128
- Asymmetric: **RSA-2048+** or **ECDSA (P-256/384/521)**
- Hashing: **SHA-256+** (never MD5, SHA-1)
- Key derivation: **PBKDF2** (100k+ iterations), bcrypt, Argon2
- [ ] **Key Management Lifecycle**:
- Generate: Cryptographically secure RNG only
- Store: Level * = encrypted software; Level ** = hardware token; Level *** = HSM
- Rotate: Annual minimum (monthly for critical systems)
- Destroy: Secure deletion per NIST 800-88
- [ ] **Data Protection**:
- Database: Encrypt sensitive fields (PII, credentials) with AES-256-GCM
- Full-disk encryption where applicable
- Backups encrypted with separate keys
- Keys never in code, logs, or config files
- [ ] **Certificates** (if implementing signature/authentication):
- X.509 v3 from qualified PSCE (Prestataire de Services de Certification Électronique)
- Proper revocation checking (OCSP/CRL)
- Certificate chain validation to trusted root (IGC/A for French admin systems)
📌 **Reference Documentation**: See [RGS-ANNEX-B2-DETAILED.md](./RGS-ANNEX-B2-DETAILED.md) for comprehensive implementation guide covering algorithms, certificate types, timestamping, key management phases, and security level mappings.
---
```typescript
// ✅ AES-256-GCM encryption (RGS-compliant) — Framework-agnostic pseudocode
// Implementation varies by language (Node.js, Python, Java, Go, etc.)
const encryptData = (plaintext: string, key: Buffer): string => {
// 1. Generate random IV (initialization vector) 16 bytes
const iv = generateRandomBytes(16)
// 2. Create AES-256-GCM cipher with key
const cipher = createCipheriv('aes-256-gcm', key, iv)
// 3. Encrypt data
const encrypted = cipher.update(plaintext, 'utf-8', 'hex') + cipher.final('hex')
// 4. Get authentication tag (ensures integrity)
const authTag = cipher.getAuthTag()
// 5. Return IV:AuthTag:Ciphertext (needed for decryption)
return `${iv.toString('hex')}:${authTag.toString('hex')}:${encrypted}`
}
const decryptData = (ciphertext: string, key: Buffer): string => {
const [ivHex, tagHex, encrypted] = ciphertext.split(':')
const iv = Buffer.from(ivHex, 'hex')
const authTag = Buffer.from(tagHex, 'hex')
// 1. Create AES-256-GCM decipher
const decipher = createDecipheriv('aes-256-gcm', key, iv)
// 2. Set authentication tag (validates integrity)
decipher.setAuthTag(authTag)
// 3. Decrypt
return decipher.update(encrypted, 'hex', 'utf-8') + decipher.final('utf-8')
}
// ✅ PBKDF2 for password hashing (RGS-compliant)
// Pseudocode - use standard library or library like bcrypt
const hashPassword = (password: string): string => {
const salt = generateRandomBytes(32)
// PBKDF2 with SHA-256, 100,000+ iterations
const hash = pbkdf2(password, salt, 100000, 64, 'sha256')
return `${salt.toString('hex')}:${hash.toString('hex')}`
}
// ✅ TLS 1.3 configuration (framework-agnostic)
// Example: ExpressJS, NestJS, FastAPI, Spring, etc.
const serverConfig = {
keyFile: '/etc/ssl/private/server.key', // Private key
certFile: '/etc/ssl/certs/server.crt', // Certificate
minVersion: 'TLSv1.3', // Minimum TLS 1.3
ciphers: 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256', // Strong ciphers
enableHSTS: true, // HTTP Strict Transport Security
}
Focus Area: Critical for Web Apps & APIs (⭐⭐⭐)
Why This Matters: Most attacks enter through input (SQL injection, XSS, CSRF). Validation stops them at the door
Quick Assessment: Are all user inputs validated against a whitelist? Is CSRF token check implemented?
SQL Injection Prevention:
XSS (Cross-Site Scripting) Prevention:
CSRF (Cross-Site Request Forgery) Protection:
Input Validation (RGS recommendation):
File Upload Security:
Rate Limiting & DoS Prevention:
// ✅ Input validation (RGS-compliant) — Framework-agnostic example
// Following principle: validate ALL inputs against strict whitelist schema
class UserInput {
// Schema validation examples:
email: string // Must be valid email format
username: string // 3-50 chars, alphanumeric + underscore only
age: number // 18-120
country: string // Max 2 chars, uppercase only
validate(): ValidationErrors {
const errors = []
// ✅ Format validation
if (!isValidEmailFormat(this.email)) {
errors.push('Invalid email format')
}
// ✅ Length validation
if (this.username.length < 3 || this.username.length > 50) {
errors.push('Username must be 3-50 characters')
}
// ✅ Pattern validation (whitelist allowed chars)
if (!/^[a-zA-Z0-9_]+$/.test(this.username)) {
errors.push('Username can only contain letters, numbers, underscore')
}
// ✅ Range validation
if (this.age < 18 || this.age > 120) {
errors.push('Age must be 18-120')
}
return errors
}
}
// ✅ CSRF token validation (framework-agnostic)
// On every state-changing request (POST, PUT, DELETE):
const validateCSRFToken = (requestToken: string, sessionToken: string): boolean => {
// Token must match - prevents cross-site attacks
return requestToken === sessionToken && requestToken !== null
}
// ✅ XSS prevention - output encoding (framework-agnostic)
// Encode output based on context:
const encodeHTML = (text: string): string => {
// Replace special chars: < > & " '
return text
.replace(/&/g, '&')
.replace(/</g, '<')
.replace(/>/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''')
}
const encodeJavaScript = (text: string): string => {
// Escape for JavaScript strings
return JSON.stringify(text)
}
// ✅ File upload validation (framework-agnostic)
const validateFileUpload = (file: UploadedFile): ValidationErrors => {
const errors = []
// Check file type (magic bytes, not just extension)
const expectedMagic = { jpg: 'FFD8FF', png: '89504E47' }
if (!hasMagicBytes(file.data, expectedMagic[file.type])) {
errors.push('Invalid file type')
}
// Check file size
const maxSize = 5 * 1024 * 1024 // 5 MB
if (file.size > maxSize) {
errors.push('File too large')
}
// Check allowed extensions (whitelist)
const allowedExt = ['jpg', 'jpeg', 'png', 'gif']
if (!allowedExt.includes(file.extension)) {
errors.push('File type not allowed')
}
return errors
}
Focus Area: Critical for ALL production systems (⭐⭐⭐)
Why This Matters: You cannot detect or investigate attacks without logs. Logs are your evidence
Quick Assessment: Are all login attempts logged? Can logs be tampered with? Are they retained 1+ year?
Audit Log Creation:
Security Events Logged:
Log Storage & Protection:
Log Retention (RGS requirement):
Log Analysis & Alerting:
Data Privacy in Logs:
// ✅ RGS-compliant structured audit logging — Framework-agnostic example
// Use JSON format for machine-parseable logs
interface AuditLogEntry {
timestamp: string // ISO 8601 format: 2026-04-01T10:30:00Z
eventType: string // 'authentication', 'data_access', 'admin_action', etc.
userId: string // User ID (NOT email, NOT PII)
resourceId?: string // What was accessed/modified
operation?: string // READ, WRITE, DELETE, UPDATE
outcome: 'success' | 'failure'
ipAddress?: string
severity: 'INFO' | 'WARN' | 'ERROR' | 'CRITICAL'
errorMessage?: string // Non-sensitive error message
}
// ✅ Authentication attempt logging
const logAuthenticationAttempt = (
userId: string,
success: boolean,
ipAddress: string
) => {
const event: AuditLogEntry = {
timestamp: new Date().toISOString(),
eventType: 'authentication',
userId: userId, // ✅ OK to log
outcome: success ? 'success' : 'failure',
ipAddress: ipAddress,
severity: success ? 'INFO' : 'WARN',
}
// Log as JSON string (machine-readable)
logToSecureStorage(JSON.stringify(event))
// Alert system if failure (brute force detection)
if (!success) {
checkBruteForcePattern(userId)
}
}
// ✅ Data access logging
const logDataAccess = (userId: string, resourceId: string, operation: string) => {
const event: AuditLogEntry = {
timestamp: new Date().toISOString(),
eventType: 'data_access',
userId: userId,
resourceId: resourceId,
operation: operation,
outcome: 'success',
severity: 'INFO',
}
logToSecureStorage(JSON.stringify(event))
}
// ✅ Admin action logging
const logAdminAction = (adminId: string, action: string, targetId: string) => {
const event: AuditLogEntry = {
timestamp: new Date().toISOString(),
eventType: 'admin_action',
userId: adminId,
resourceId: targetId,
operation: action,
outcome: 'success',
severity: 'WARN', // Admin actions are always important
}
logToSecureStorage(JSON.stringify(event))
}
// ✅ NEVER log sensitive data
// ❌ WRONG:
logToSecureStorage(
JSON.stringify({
userId: user.id,
password: user.password, // ❌ NEVER
creditCard: user.creditCard, // ❌ NEVER
ssn: user.ssn, // ❌ NEVER
apiKey: process.env.API_KEY, // ❌ NEVER
})
)
// ✅ CORRECT:
logToSecureStorage(
JSON.stringify({
userId: user.id, // ✅ OK
action: 'password_reset', // ✅ OK (action, not the actual password)
timestamp: new Date().toISOString(), // ✅ OK
})
)
Focus Area: Important for ALL projects (⭐⭐⭐)
Why This Matters: Known vulnerabilities are exploited within days. Patches prevent this
Quick Assessment: When was the last dependency scan? Do you have a patch policy? How long until critical patches are applied?
Dependency Scanning:
Security Updates:
Penetration Testing & Vulnerability Assessment:
Threat Monitoring (RGS requirement):
Focus Area: Important for projects with integrations (⭐⭐⭐)
Why This Matters: Your security is only as strong as your weakest vendor. A vendor breach can compromise you
Quick Assessment: Do you have vendor security requirements? Are third-party services audited?
// ✅ Vendor/Third-party security assessment (framework-agnostic)
interface VendorSecurityAssessment {
vendorName: string
// Certifications
securityCertifications: string[] // ISO 27001, SOC 2, etc.
certificationExpiry: Date
// Compliance
dataProcessingAgreement: Date // When DPA signed?
dpaStatus: 'signed' | 'pending' | 'rejected'
// Security testing
lastPenetrationTest: Date
lastSecurityAudit: Date
// Incident history
pastBreaches: boolean
breachDetails?: string
// Responsiveness
vulnerabilityResponsiveness: 'FAST' | 'MEDIUM' | 'SLOW' | 'UNKNOWN'
// Decision
approved: boolean
approvalDate: Date
nextReviewDate: Date
riskLevel: 'LOW' | 'MEDIUM' | 'HIGH'
}
Focus Area: Critical for production systems (⭐⭐⭐)
Why This Matters: Attacks will happen. Well-prepared teams recover faster and suffer less damage
Quick Assessment: Do you have an incident response plan? Who calls the response? How do you resume operations?
// ✅ Incident response tracking (framework-agnostic)
interface IncidentResponse {
id: string // Unique incident ID
reportedAt: Date
severity: 'LOW' | 'MEDIUM' | 'HIGH' | 'CRITICAL'
// Detection phase
detectionMethod: string // How detected? (log analysis, user report, IDS, etc.)
detectionTime: Date
// Initial response
containmentStarted: Date
containedSystems: string[] // Systems isolated
// Remediation
shortTermMeasures: string[] // Temporary fixes applied
permanentFix: string // Long-term solution
fixDeployedAt: Date
// Review (mandatory after every incident)
rootCauseAnalysis: string // Why did it happen?
preventionMeasures: string[] // How to prevent recurrence?
postMortemDate: Date
resolutionTime: number // Time to resolve (hours)
}
If you are an RGS compliance agent analyzing a project, follow this workflow:
For each applicable phase:
-DETAILED.md file for context| Pitfall | Risk | Fix |
|---|---|---|
| Weak password policy | Easily guessed passwords | Enforce 12+ chars, complexity |
| No MFA | Account compromise | Require MFA for sensitive accounts |
| Storing passwords in plain-text | Immediate compromise if breached | Hash with bcrypt, argon2 |
| Logging sensitive data | Exposure in logs | Sanitize logs, no PII |
| No rate limiting | Brute force attacks | Throttle failed login attempts |
| Hardcoded secrets in code | Secrets leaked in git history | Use environment variables |
| No audit logging | Can't detect/investigate breaches | Log all critical actions |
| Outdated dependencies | Known vulnerabilities | Update regularly, scan with npm audit |
SKILL.md (THIS FILE)
├─ Definition & Objectives
├─ Quick Start (diagnostic questions + matrix)
├─ 5-Step RGS Process
├─ 8 Implementation Phases (checklists)
│ ├─ Phase 1: Risk Management
│ ├─ Phase 2: Authentication → See RGS-ANNEX-B3-DETAILED.md
│ ├─ Phase 3: Encryption → See RGS-ANNEX-B2-DETAILED.md
│ ├─ Phase 4: Input Validation
│ ├─ Phase 5: Audit Logging
│ ├─ Phase 6: Vulnerability Management
│ ├─ Phase 7: Third-Party Risk
│ └─ Phase 8: Incident Response
├─ Common Pitfalls
├─ Tools & Resources
└─ This Summary
RGS-ANNEX-B2-DETAILED.md
├─ Comprehensive cryptography reference
├─ Algorithm requirements
├─ Key lifecycle
├─ Certificate management
└─ ~2000 lines of detailed context
RGS-ANNEX-B3-DETAILED.md
├─ Comprehensive authentication reference
├─ Authentication models
├─ Session lifecycle
├─ Unlock mechanisms
├─ Audit requirements
└─ ~2000 lines of detailed context
/docs/compliance/RGS-IMPLEMENTATION.md
├─ Project-specific patterns (NestJS, React, PostgreSQL)
├─ Code examples (Passport.js, JWT, bcrypt)
├─ Database schema (User, Session, AuditLog tables)
├─ API endpoint examples
└─ Project-specific best practices
Security Officer:
Developer (Implementing Auth):
Developer (Handling Encryption):
Compliance Agent:
Last Updated: 1 April 2026 | RGS Version: v2.0 (2014), v3.0 guidance emerging
Maintained by: ANSSI Reference | For: Project Compliance Framework
Organizations must ensure continuity and recovery capability in case of security incidents or disasters:
Before deploying to production, verify that the system meets all RGS requirements:
⚠️ Project-specific guidance (e.g., Project NestJS/React implementation) is NOT in this skill file.
Instead, see Project Documentation for implementation details:
docs/compliance/Project-RGS-IMPLEMENTATION.md— Project's specific RGS requirements & code examplesThis skill focuses on RGS reference knowledge only, not project-specific implementation.
The RGS framework is organized into 10 chapters + annexes: