Qu'est-ce qu'un AppSec engineer ? Fiche métier

Un AppSec engineer (Application Security engineer) est un professionnel cybersécurité spécialisé dans la sécurité des applications logicielles tout au long du cycle de vie de développement (SDLC : Software Development Life Cycle). Cinq activités principales structurent son quotidien : threat modeling avant dev (20-25 %), revue de code sécurité sur PR critiques (20-25 %), pentest applicatif manuel via Burp Suite Pro (20-25 %), formation des équipes dev (15-20 %), incident response sur vulnérabilités applicatives (5-10 %). Le métier se distingue du DevSecOps (qui automatise la sécurité à l'échelle via pipelines CI/CD) et du pentester web (qui fait du test ponctuel en mission de 5-15 jours) : l'AppSec engineer est attaché à un produit ou équipe produit en continu. Salaires juniors 50-70 k€ bruts IDF — parmi les plus élevés du cyber junior grâce au socle dev valorisé. Progression senior 85-115 k€, staff 100-140 k€. Cet article détaille la définition précise, la distinction avec DevSecOps et pentest web, les 5 activités principales, le cadre SDLC, la stack technique, les salaires et le profil qui réussit dans le métier.

1. Définition précise : qu'est-ce qu'un AppSec engineer ?

L'AppSec engineer est le garant de la sécurité des applications d'une équipe produit, d'un portefeuille d'applications ou d'une ligne business. Trois caractéristiques structurent le rôle.

Attachement produit, pas attachement outillage

Contrairement au DevSecOps qui construit les pipelines CI/CD transverses de l'organisation, l'AppSec engineer est intégré dans une équipe produit (une app majeure, un portefeuille, une ligne business). Il connaît intimement l'application, ses utilisateurs, ses flux de données sensibles, ses dépendances. Cette connaissance contextuelle permet une sécurité plus ciblée et opérationnelle qu'un DevSecOps transverse.

Hands-on technique, pas orchestration

L'AppSec fait principalement du hands-on : lire du code, exploiter manuellement avec Burp Suite, écrire des PoC, animer des ateliers threat modeling. Il utilise les outils DevSecOps (SAST, DAST, SCA) mais les complémente par du travail humain qu'aucun outil ne remplace : revue contextualisée de logique métier, validation de threat models, exploitation de chemins d'attaque non triviaux.

Couverture complète du SDLC

Le métier couvre l'intégralité du cycle de vie applicatif : phase conception (threat modeling), phase dev (code review, secure coding guidelines), phase test (pentest applicatif, bug bounty triage), phase production (monitoring WAF, incident response applicatif), phase maintenance (mise à jour dépendances, patches vulnérabilités 0day).

2. AppSec vs DevSecOps vs pentester web : distinctions

Trois métiers techniques proches avec chevauchements mais positionnements distincts. Tableau comparatif opérationnel.

Recouvrement en PME / scale-up : une seule personne cumule souvent AppSec + DevSecOps. Les deux rôles ne se distinguent vraiment qu'en grande entreprise avec équipes séparées (banques, scale-ups matures 500+ personnes).

Recouvrement avec pentester : l'AppSec fait du pentest applicatif en interne, le pentester externe fait du pentest en mission client. Le pentester web passe souvent en AppSec à 3-5 ans d'expérience, attiré par le travail continu avec les devs plutôt que les missions courtes. Pour approfondir, voir Qu'est-ce qu'un pentester ? et Qu'est-ce qu'un DevSecOps ?.

3. Les cinq activités principales de l'AppSec engineer

Répartition type du temps d'un AppSec junior dans une scale-up tech (équipe produit 30-80 devs).

Threat modeling (20-25 %)

Modélisation des menaces pesant sur une fonctionnalité avant son développement. Méthodologies principales :

• STRIDE (Microsoft) : Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
• PASTA (Process for Attack Simulation and Threat Analysis) : plus itératif, 7 étapes.
• Attack Trees : représentation hiérarchique des chemins d'attaque.
• LINDDUN pour les aspects vie privée / RGPD.

Exemple concret de threat model structuré en YAML pour une fonctionnalité de « reset password » :

threat_model_reset_password:
  feature: "Reset password via email token"
  assets_proteges:
    - "Comptes utilisateurs"
    - "Adresses email"
    - "Tokens de reset en base"
 
  acteurs:
    legitimes:
      - "Utilisateur final"
      - "Systeme email transactionnel"
    adversaires:
      - "Attaquant externe anonyme"
      - "Attaquant avec un compte valide (insider)"
 
  assumptions:
    - "TLS obligatoire sur tout acces API"
    - "Rate limiting en place sur endpoint auth"
    - "Token de reset stocke hashe en base"
 
  threats_STRIDE:
    spoofing:
      - threat: "Attaquant intercepte lien reset via XSS sur email client"
        severity: "high"
        mitigation: "token a usage unique + expiration 15 min + link preview disabled"
      - threat: "Enumeration des emails valides via timing ou message different"
        severity: "medium"
        mitigation: "meme reponse HTTP et meme timing pour email valide / invalide"
 
    tampering:
      - threat: "Attaquant modifie le token dans l'URL pour collision"
        severity: "high"
        mitigation: "token >= 128 bits entropy genere par secrets.token_urlsafe"
 
    repudiation:
      - threat: "Utilisateur nie avoir demande le reset"
        severity: "low"
        mitigation: "logging IP + user-agent + timestamp dans table auth_events"
 
    information_disclosure:
      - threat: "Token log dans application logs ou proxy"
        severity: "high"
        mitigation: "redaction automatique des query params sensibles + log level audit"
 
    denial_of_service:
      - threat: "Spamming de reset pour epuiser quota email"
        severity: "medium"
        mitigation: "rate limit 3 req / heure / email + captcha apres 2 echecs"
 
    elevation_of_privilege:
      - threat: "Token reset admin permet de prendre compte admin"
        severity: "critical"
        mitigation: "MFA obligatoire re-trigger apres reset admin + approbation manuelle"
 
  references:
    - "OWASP ASVS V2 Authentication"
    - "OWASP Forgot Password Cheat Sheet"

Ce type de threat model est typiquement produit en 2-4 heures par l'AppSec, partagé en revue avec l'équipe dev en 1 heure d'atelier, puis intégré comme acceptance criteria de la feature avant merge.

Code review sécurité (20-25 %)

Revue humaine de pull requests sur des chemins critiques :

• Authentication, authorization, session management.
• Manipulation de données sensibles (paiement, santé, PII).
• Upload/download de fichiers.
• Cryptographie appliquée.
• Intégration de bibliothèques tierces non auditées.

L'AppSec ne revoit pas 100 % des PR (trop volumique) mais configure des CODEOWNERS automatiques sur les fichiers sensibles et intervient sur alerte. Complément hardware des outils SAST automatisés.

Pentest applicatif manuel (20-25 %)

Pentest interne en continu sur l'application :

• Tests Burp Suite Pro : IDOR, broken access control, SSRF, business logic flaws non détectables par SAST.
• Tests API : authorization horizontal/vertical, rate limiting, abuse cases.
• Tests pre-release : sprint de pentest avant chaque feature majeure.
• Triage de bug bounty : validation des rapports externes reçus sur YesWeHack ou Intigriti.

Formation et coaching des équipes dev (15-20 %)

• Ateliers OWASP Top 10 adaptés au stack (Python, Go, Node, Java).
• Pair coding sécurité sur features sensibles.
• Documentation secure coding guidelines interne.
• Conférences internes sur nouveaux patterns d'attaque ou CVE majeures (Log4Shell, xz-utils).

Incident response applicatif (5-10 %)

Intervention sur vulnérabilités découvertes en production (bug bounty critique, CVE exploitée, rapport responsible disclosure) : triage, reproduction, coordination du patch avec dev, communication utilisateurs si impact.

4. Le SDLC sécurisé : le cadre de travail de l'AppSec

L'AppSec opère dans le cadre du Secure Software Development Life Cycle (SSDLC), qui intègre la sécurité dans les 6 phases classiques du SDLC.

OWASP ASVS (Application Security Verification Standard) est le référentiel central : 4 niveaux de vérification (L1 basique à L4 applications critiques), ~300 requirements mesurables. L'AppSec engineer s'appuie dessus pour définir la barre qualité minimale par application selon criticité.

5. Stack d'outils et méthodologies

Outils pentest applicatif (majorité des AppSec)

• Burp Suite Professional : 449 $ / utilisateur / an. Référence absolue, 80 % du temps pentest web.
• OWASP ZAP : gratuit, alternative open source.
• Postman + Newman : test API sécurisé, collections partageables.
• sqlmap, XSStrike, SSRFmap : outils spécialisés.

Outils SAST / SCA (complément DevSecOps)

• Semgrep : référence open source SAST, règles custom.
• SonarQube : standard entreprise.
• CodeQL : GitHub Advanced Security, requêtes SQL-like.
• Trivy, Snyk : SCA et container security.

Outils threat modeling

• Microsoft Threat Modeling Tool (TMT) : gratuit, STRIDE basique.
• OWASP Threat Dragon : open source, web-based.
• IriusRisk : SaaS commercial pour grandes organisations.
• drawio + template STRIDE : low-tech, très efficace pour PME / scale-up.

Référentiels clés

• OWASP Top 10 2021 (update 2025 en cours) : classique, incontournable.
• OWASP ASVS v4 : requirements détaillés.
• OWASP API Security Top 10 2023 : spécialisé API.
• OWASP MSTG / MASVS : mobile.
• NIST SP 800-218 (SSDF : Secure Software Development Framework).
• SAFECode best practices.

6. Salaires et trajectoires

Trajectoire salariale

Fourchettes Apec Cadres 2023-2024, Numeum, observatoires LinkedIn France. Les AppSec avec portfolio GitHub actif (règles Semgrep publiques, outils OWASP contribués, blog technique) tirent systématiquement la fourchette haute.

Employeurs types en France 2026

• Scale-ups et licornes tech : Doctolib, Swile, Alan, Dataiku, Algolia, Mistral AI, Shift Technology, Ankorstore. Équipes AppSec 2-8 personnes en forte croissance.
• Banques et fintech : Société Générale, BNP Paribas, Crédit Agricole, Natixis, Qonto, Lydia. Équipes AppSec souvent 15-40 personnes.
• Éditeurs produit : OVHcloud, Scaleway, Outscale, Dassault Systèmes, Sopra Steria Produits.
• ESN pentest offensive (pôle AppSec) : Synacktiv, Almond, LEXFO, Intrinsec. Plus tourné vers mission pentest que AppSec interne strict.
• E-commerce : Leboncoin, ManoMano, Vinted, Veepee.

Bifurcations classiques

• Staff AppSec engineer : principal AppSec d'un périmètre critique, reporting direct au RSSI ou CTO.
• Security Engineer : construction d'outils internes, moins de coordination équipe produit.
• Consultant AppSec indépendant : TJM 800-1 300 €, carnet clients scale-ups et banques.
• Product Security Manager : management d'une équipe de 3-8 AppSec.
• Bascule RSSI : AppSec senior → RSSI PME. Voir Les étapes pour devenir RSSI.

7. Pour qui le métier d'AppSec convient-il ?

Traits qui fonctionnent en AppSec

• Socle dev préalable solide : 2-5 ans d'expérience développeur avant la bascule. L'AppSec lit du code tous les jours.
• Goût pour la coordination équipe produit : l'AppSec travaille en permanence avec devs, PM, designers. Pas de rôle solo.
• Patience pédagogique : former des devs non sensibilisés à la sécurité demande répétition, reformulation, exemples concrets.
• Mindset offensif-défensif : penser comme un attaquant pour proposer des mitigations pragmatiques aux devs.
• Veille active : OWASP, CVE critiques, articles de recherche (Portswigger, HackerOne reports).

Traits qui signalent un mauvais match

• Rejet de la coordination équipe produit quotidienne.
• Préférence pour les missions courtes avec livrable tranché → plutôt pentester en ESN.
• Rejet de la pédagogie → plutôt security engineer backend.
• Pas de background dev préalable → 12-18 mois de formation socle avant bascule possible.

Trajectoires d'entrée en AppSec junior

• Via développement : dev backend 2-4 ans → AppSec junior. Trajectoire la plus rapide (6-12 mois bascule). Voir Quel métier cyber viser quand on vient du développement ?.
• Via pentest : pentester junior 2-3 ans → AppSec en bascule interne client. Classique quand un pentester veut se fixer sur un produit.
• Via bootcamp AppSec dédié : rare mais existe (peu de bootcamps spécialisés AppSec en France en 2026).

Points clés à retenir

• AppSec engineer = sécurité applicative sur l'ensemble du SDLC, attaché à un produit ou portefeuille. Prévenir > détecter.
• 5 activités principales : threat modeling (20-25 %), code review (20-25 %), pentest manuel (20-25 %), formation dev (15-20 %), incident response (5-10 %).
• Distinction DevSecOps : DevSecOps = pipelines transverses 50-500+ repos ; AppSec = produit attaché, hands-on humain.
• Distinction pentest : pentest = mission 5-15 jours ponctuelle ; AppSec = cycle continu attaché au produit.
• Stack technique : Burp Suite Pro (80 % du temps pentest), Semgrep, OWASP Top 10, OWASP ASVS, MS Threat Modeling Tool.
• Salaires juniors 50-70 k€ IDF — parmi les plus élevés du cyber junior grâce au socle dev valorisé.
• Bascule idéale : dev backend 2-5 ans expérience → AppSec junior en 6-12 mois.

Pour l'ensemble des métiers cyber avec salaires et accessibilité par profil, voir Les métiers de la cybersécurité : guide complet. Pour comparer avec les métiers voisins, voir Qu'est-ce qu'un DevSecOps ? Fiche métier complète, Qu'est-ce qu'un pentester ? Fiche métier complète, et Qu'est-ce qu'un blue teamer ? Fiche métier complète. Pour la bascule depuis un profil développeur qui est la trajectoire la plus naturelle vers AppSec, voir Quel métier cyber viser quand on vient du développement ?. La formation OWASP Web Security de Zeroday couvre exactement ce socle AppSec : OWASP Top 10 en profondeur, exploitation web pratique avec Burp Suite, threat modeling STRIDE, revue de code sécurisée et méthodologie pentest applicatif.