The SPW Digital manages a portfolio of approximately 800 applications, including nearly 400 web applications, relying on a variety of technologies and service providers. Poor control of their lifecycle can result in:

• an interruption of public services;
• a compromise of data or application functions;
• the exploitation of vulnerabilities in code, components, or configurations;
• an increase in technical debt and risks of obsolescence;
• non-compliance with security requirements, particularly NIS2, CyFun, and the SPW Information Security Program;
• longer and more expensive fixes when security is addressed too late.

To address these risks, the SPW Digital Security Division has a dedicated team for Secure Application Lifecycle Management (SALM). Their main responsibilities include:

• determining the criticality of applications and the security controls to be applied;
• conducting risk analyses and tracking the implementation of decided measures according to the methodology in place at SPW;
• defining the application security standards and practices for SPW;
• integrating security controls into projects and DevSecOps/CI/CD pipelines: SAST, DAST, SCA, vulnerability scans, and penetration testing;
• tracking exemptions, residual risks, and recommendations before production launch;
• ensuring the monitoring of vulnerabilities, obsolescence, and decommissioning of applications;
• advising project, development, architecture, and operations teams.

The team works with project managers, developers, architects, operations, functional managers, service centers, DevSecOps and SecOps teams, the SOC, business units, and service providers.

The objective is to replace ad hoc and manual controls with a common approach, proportionate to the risks, more automated, and covering the entire application lifecycle.

Expected Behavioral Competencies

Analytical mindset: structure a complex situation and distinguish priority risks.
Pragmatism: propose proportionate, realistic, and verifiable measures.
Pedagogy: make security requirements understandable for projects and business units.
Rigor: document assumptions, decisions, evidence, and residual risks.
Autonomy: manage several files in parallel.
Collaboration: work with developers, architects, DevSecOps, operations, and vendors.

Description of the Mission

Main Mission

Take charge of the risks and requirements aspects of SALM files. Support projects from the initial qualification through to production launch, ensuring that controls are appropriate to the application's criticality and that decisions are traceable.

All members of the SALM team report hierarchically to the head of the GRC & application security sub-division (currently managed ad interim by the head of the security division).

Key Activities

Domain | Key Activities
--- | ---
Qualification and criticality |
Risks and threats |
Architecture and requirements |
Project support |
Review and production launch |
Continuous improvement |

Examples of Deliverables

• Qualification and criticality assessment sheet.
• Risk analysis or threat model.
• Security requirements and control plan.
• Architecture or design review report.
• Register of recommendations, exemptions, and residual risks.
• SALM opinion before production launch.