Shift Left Security

---

1 - Le concept Shift Left

1.1 Définition

Shift Left = Déplacer les activités de sécurité vers le début du cycle de développement.

1.2 Avantages

Avantage	Impact
Coût réduit	100x moins cher qu'en production
Délai raccourci	Pas de retours en fin de cycle
Qualité améliorée	Moins de dette technique
Culture	Développeurs sensibilisés

---

2 - Threat Modeling

2.1 Méthodologie STRIDE

2.2 Process de Threat Modeling

threat_modeling_steps:
  1_decompose:
    - Identifier les composants
    - Définir les trust boundaries
    - Mapper les flux de données
  
  2_identify_threats:
    - Appliquer STRIDE à chaque composant
    - Documenter les scénarios d'attaque
    - Évaluer la probabilité
  
  3_mitigate:
    - Définir les contrôles
    - Prioriser par risque
    - Assigner aux équipes
  
  4_validate:
    - Vérifier l'implémentation
    - Tests de sécurité
    - Review périodique

2.3 Exemple de Threat Model

# threat-model.yaml
application: E-Commerce API
version: 1.0
date: 2024-01-15

components:
  - name: API Gateway
    type: entry_point
    threats:
      - type: Spoofing
        description: "Attaquant usurpe l'identité d'un user"
        mitigation: "OAuth2 + MFA"
        status: mitigated
      - type: DoS
        description: "Flood de requêtes"
        mitigation: "Rate limiting + WAF"
        status: mitigated

  - name: Database
    type: data_store
    threats:
      - type: Information Disclosure
        description: "Accès non autorisé aux données"
        mitigation: "Encryption at rest + RBAC"
        status: mitigated
      - type: Tampering
        description: "Modification des données"
        mitigation: "Audit logs + Integrity checks"
        status: in_progress

trust_boundaries:
  - name: Internet to DMZ
    controls: [WAF, IDS, TLS]
  - name: DMZ to Internal
    controls: [Firewall, mTLS]

---

3 - Security Requirements

3.1 User Stories sécurisées

# Template User Story avec Sécurité

**En tant que** [rôle]
**Je veux** [action]
**Afin de** [bénéfice]

## Critères d'acceptation
- [ ] Critère fonctionnel 1
- [ ] Critère fonctionnel 2

## Critères de sécurité
- [ ] Authentification requise
- [ ] Autorisation vérifiée (RBAC)
- [ ] Input validé et sanitized
- [ ] Données sensibles chiffrées
- [ ] Audit log généré

3.2 Security Requirements Checklist

# OWASP ASVS basé
authentication:
  - Multi-factor authentication support
  - Secure password storage (bcrypt/argon2)
  - Session management secure
  - Account lockout after failures

authorization:
  - Role-based access control
  - Principle of least privilege
  - API authorization on all endpoints
  - Resource-level permissions

data_protection:
  - Encryption at rest (AES-256)
  - Encryption in transit (TLS 1.3)
  - PII handling compliant
  - Secure key management

input_validation:
  - Input validation on all inputs
  - Output encoding
  - SQL injection prevention
  - XSS prevention

logging:
  - Security events logged
  - No sensitive data in logs
  - Log integrity protected
  - Centralized logging

---

4 - Secure Coding Guidelines

4.1 Top 10 règles

Règle	Description
1. Input Validation	Valider toutes les entrées
2. Output Encoding	Encoder les sorties (XSS)
3. Parameterized Queries	Prévenir SQL injection
4. Authentication	Authentification robuste
5. Access Control	Contrôle d'accès strict
6. Cryptography	Crypto moderne et correcte
7. Error Handling	Pas d'info sensible dans les erreurs
8. Logging	Logger les événements sécurité
9. Data Protection	Protéger les données sensibles
10. HTTP Security	Headers sécurité HTTP

4.2 Exemples de code sécurisé

# ❌ MAUVAIS - SQL Injection
query = f"SELECT * FROM users WHERE id = {user_id}"

# ✅ BON - Parameterized Query
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_id,))

// ❌ MAUVAIS - XSS
element.innerHTML = userInput;

// ✅ BON - Encoding
element.textContent = userInput;

# ❌ MAUVAIS - Hardcoded secret
api_key = "sk-12345secret"

# ✅ BON - Environment variable
api_key = os.environ.get("API_KEY")

---

5 - Code Review sécurité

5.1 Checklist de review

## Security Code Review Checklist

### Authentication & Authorization
- [ ] Authentification requise pour les endpoints sensibles
- [ ] Autorisation vérifiée côté serveur
- [ ] Session management sécurisé

### Input/Output
- [ ] Toutes les entrées validées
- [ ] Sorties encodées correctement
- [ ] File uploads sécurisés

### Data
- [ ] Données sensibles chiffrées
- [ ] Pas de secrets hardcodés
- [ ] PII gérées correctement

### Error Handling
- [ ] Erreurs ne révèlent pas d'info sensible
- [ ] Exceptions gérées proprement

### Logging
- [ ] Events sécurité loggés
- [ ] Pas de données sensibles dans les logs

5.2 Automatisation avec Semgrep

# .semgrep.yml
rules:
  - id: hardcoded-password
    patterns:
      - pattern: password = "..."
    message: "Hardcoded password detected"
    severity: ERROR
    
  - id: sql-injection
    patterns:
      - pattern: |
          $QUERY = f"... {$VAR} ..."
          $CURSOR.execute($QUERY)
    message: "Potential SQL injection"
    severity: ERROR
    
  - id: insecure-hash
    patterns:
      - pattern: hashlib.md5(...)
      - pattern: hashlib.sha1(...)
    message: "Use SHA-256 or better"
    severity: WARNING

---

6 - Pre-commit Hooks

6.1 Configuration

# .pre-commit-config.yaml
repos:
  # Secrets detection
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
  
  # Security linting
  - repo: https://github.com/PyCQA/bandit
    rev: 1.7.5
    hooks:
      - id: bandit
        args: ['-r', 'src/', '-ll']
  
  # Semgrep
  - repo: https://github.com/returntocorp/semgrep
    rev: v1.50.0
    hooks:
      - id: semgrep
        args: ['--config', 'auto', '--error']

6.2 Installation

# Installer pre-commit
pip install pre-commit

# Installer les hooks
pre-commit install

# Exécuter manuellement
pre-commit run --all-files

---

7 - IDE Security Plugins

7.1 Extensions recommandées

IDE	Extension	Fonction
VS Code	Snyk	SCA + SAST
VS Code	GitLens + GitLeaks	Secrets
VS Code	SonarLint	SAST
IntelliJ	Snyk	SCA + SAST
IntelliJ	SonarLint	SAST

7.2 Configuration VS Code

// settings.json
{
  "sonarlint.rules": {
    "typescript:S2068": {
      "level": "on"  // Hardcoded credentials
    },
    "typescript:S5542": {
      "level": "on"  // Encryption mode
    }
  },
  "snyk.features.openSourceSecurity": true,
  "snyk.features.codeSecurity": true
}

---

Résumé

Dans ce chapitre, nous avons appris :

• Le concept Shift Left
• Le Threat Modeling avec STRIDE
• Les Security Requirements
• Les Secure Coding Guidelines
• La Code Review sécurité
• Les Pre-commit Hooks
• Les IDE Security Plugins

---

Prochaine étape

Dans le prochain chapitre, nous verrons SAST et DAST.

→ Chapitre suivant : SAST et DAST

---

← Retour à la table des matières