Approved secure SDLC
Secure development policy, secure coding standard and application security standard, approved and mapped to ECC 1-6 and SAMA CSF 3.3.6.
DevSecOps implementation
Ship software with security built in.
Limaz embeds practical security decisions, checks, and evidence into the way engineering teams design, build, release, and operate software.
Security that fits the delivery path
DevSecOps assigns security decisions, controls, feedback loops, and ownership throughout software delivery. Teams can address risk without routing every release through an exception process.
Limaz starts from the current software lifecycle and risk profile, then adds the smallest effective control at the point where it can prevent or shorten remediation.
What gets implemented
- Secure delivery model
- Roles, risk tiers, release criteria, exception authority, and evidence requirements.
- Design controls
- Threat modeling, architecture review, security requirements, and abuse-case analysis.
- Code and dependency controls
- SAST, software composition analysis, license rules, and actionable findings.
- Secrets and pipeline security
- Credential handling, protected variables, runner permissions, artifact integrity, and branch controls.
- Application testing
- DAST, API testing, and container and infrastructure-as-code checks.
- Gates and remediation
- Risk-based thresholds, ownership, service levels, exceptions, retesting, and closure evidence.
- Metrics and handover
- Measures that show coverage and remediation health, with runbooks for engineering and security teams.
What NCA, SAMA and PCI DSS require for secure development
Saudi regulators write secure development into their frameworks. The National Cybersecurity Authority (NCA) Essential Cybersecurity Controls (ECC-2:2024), control 1-6-3, require software projects to use secure coding standards, use trusted and licensed sources for development tools and libraries, test software against the entity's cybersecurity requirements, integrate applications securely, and review secure configuration, hardening and update packages before launch. Control 1-6-2 adds vulnerability assessment and remediation for every project and change.
The Saudi Central Bank (SAMA) Cyber Security Framework (CSF), section 3.3.6 Application Security, requires development to follow an approved secure system development life cycle (SDLC) methodology. The application security standard must cover secure coding, security configuration and logging, identity and access management, segregation of duties backed by an authorisation matrix, data protection aligned with classification, vulnerability and patch management, backup and recovery, and periodic compliance review.
For card payments, requirement 6 of the Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 goes further: secure development based on industry standards (6.2.1), secure coding training for developers at least every 12 months (6.2.2), code review before release (6.2.3), an inventory of bespoke software and its third-party components (6.3.2), and an automated solution in front of public-facing web applications that detects and prevents attacks (6.4.2).
The Open Worldwide Application Security Project (OWASP) supplies the engineering detail. The OWASP Top 10:2025 replaces the 2021 edition, keeps Broken Access Control first and introduces Software Supply Chain Failures at third place. The Application Security Verification Standard (ASVS) 5.0.0, released in May 2025, turns risks into testable requirements at three verification levels. The Software Assurance Maturity Model (SAMM) v2 measures the whole programme across five business functions: governance, design, implementation, verification and operations.
Security built into the pipeline
- Threat modeling
- Runs at design time for new systems and significant changes. The team maps data flows, trust boundaries and abuse cases, then writes security requirements into the backlog. This is the design stage of the secure SDLC that SAMA CSF 3.3.6 expects.
- Static application security testing (SAST)
- Scans source code on every pull request for injection, weak cryptography and access control flaws, the attack classes PCI DSS 6.2.4 names. Findings appear inside the developer's merge request, where they get fixed fastest.
- Software composition analysis (SCA)
- Checks open source libraries for known vulnerabilities and licence rules, and produces a software bill of materials (SBOM). This covers the ECC requirement for trusted and licensed sources and the PCI DSS 6.3.2 software inventory.
- Secrets detection
- Blocks commits that contain keys, tokens and passwords, and scans repository history for secrets already exposed. Pipeline credentials move to a vault and become short-lived.
- Dynamic application security testing (DAST)
- Tests the running application and its APIs in staging for issues that only appear at runtime: broken authentication, session handling, missing security headers and server misconfiguration.
- Infrastructure as code (IaC) scanning
- Checks Terraform, Kubernetes manifests and cloud templates against hardening baselines before deployment, so misconfiguration is caught in review instead of in production.
- Container image scanning
- Scans base and built images for vulnerable packages, enforces approved base images and signs images so only verified artefacts deploy.
Pipeline gates that don't slow releases
A gate that blocks every build on every finding gets switched off within a month. Gates work when they block only what matters and give developers fast, precise feedback.
We tier applications by risk. Internet-facing systems, payment flows and systems holding customer data get strict gates, internal tools get lighter ones. Each gate blocks on a short list: new critical or high findings in changed code, exposed secrets, known exploited vulnerabilities in dependencies, and IaC changes that open public access. Existing findings go to a tracked backlog with a deadline instead of stopping the release.
Fast scans run on every pull request in minutes. Full scans and DAST run nightly or before release. Exceptions exist, and each one has an owner, a reason, compensating controls, approval from the right authority and an expiry date. Expired exceptions reopen automatically.
Tuning matters as much as tooling. We suppress false positives centrally, link each rule to a fix with a code example, and track the broken-build rate so the gate stays credible with engineering.
Vulnerability SLAs
- What the regulators require
- NCA ECC control 2-10-3 requires vulnerabilities to be classified by severity and remediated based on that classification and the associated risk. SAMA CSF 3.3.17 Vulnerability Management requires defined timelines to mitigate per classification and a risk-based scan frequency.
- The PCI DSS benchmark
- Requirement 6.3.3 requires critical and high security patches to be installed within one month of release. It is a practical ceiling for critical findings across all systems, not only the cardholder data environment.
- Setting the service levels
- Define a remediation deadline per severity, and tighten it for internet-facing and critical systems. Start the clock at detection, not at ticket creation. Put the table in the vulnerability management standard and get it approved by the cybersecurity function.
- Ownership
- Every finding routes to the team that owns the code or asset, with fix guidance attached. Security sets the policy and tracks progress. Engineering fixes.
- Exceptions
- A finding that misses its deadline needs a risk acceptance from an authorised owner, with compensating controls and an expiry date. Overdue findings without acceptance go to management reporting.
- Measurement
- Track mean time to remediate by severity, the share of findings closed within the service level, open critical findings per application and the age of accepted risks. These numbers show examiners the process works.
Evidence for NCA and SAMA
Examiners ask for proof that controls operate, beyond proof that tools are installed. A well-run pipeline produces this evidence as a by-product.
Threat models and requirements
Design artefacts for new systems and major changes, with security requirements traced to backlog tickets.
Scan history
SAST, SCA, DAST, IaC and container results per release, with each gate decision recorded.
Remediation records
Each finding with severity, owner, detection date, closure date and retest result, measured against the service level.
Exceptions register
Every accepted risk with its justification, approver, compensating controls and expiry date.
Change and environment records
Proof that production changes passed review and approval, and that preproduction and production are separated with enforced access controls (PCI DSS 6.5.3).
Training records
Secure coding training for developers at least every 12 months, as PCI DSS 6.2.2 requires.
Rollout
We roll DevSecOps out in stages so engineering keeps shipping throughout.
Baseline
Map current pipelines, repositories, environments and the release process. Inventory applications and rank them by risk. Measure the existing vulnerability backlog.
Policy and standards
Write the secure SDLC, secure coding standard, gate criteria, service level table and exception process. Get them approved so they carry authority.
Pilot
Turn on scanning for two or three representative applications in report-only mode. Tune rules, remove noise and agree gate thresholds with the teams.
Enforce
Switch gates to blocking for new critical and high findings, starting with the highest-risk applications. Move pipeline secrets into a vault.
Scale
Onboard remaining repositories through shared pipeline templates, so every new project inherits the controls by default.
Operate and improve
Report service level performance, coverage and exceptions monthly. Feed recurring findings back into training and coding standards. Assess the programme against OWASP SAMM to set the next targets.
Common gaps we find
- Scanners run, but findings land in a dashboard that nobody owns.
- SAST covers the main repository while microservices, mobile apps and infrastructure code go unscanned.
- No software inventory or SBOM, so each new library vulnerability triggers days of manual searching.
- Secrets in repository history, pipeline variables readable by every project and long-lived cloud keys on build runners.
- Gates set to block everything, then switched off after the first release crunch.
- Remediation deadlines written in policy but never tracked, so overdue critical findings stay invisible to management.
- Outsourced and vendor code shipped without the scans and review applied to in-house code.
- Test data and test accounts left in production, which PCI DSS 6.5.6 prohibits.
Related security work
Security control implementation
Enterprise security integrations beyond the delivery pipeline.
IAM and PAM implementation
Access, service identities, privileged accounts, and review workflows.
ISO 27001 readiness
Connect secure development evidence to the wider ISMS.
PCI DSS readiness
Secure payment software and the cardholder data environment.
Questions
DevSecOps builds security into every stage of software delivery instead of testing once before go-live. Security requirements start at design through threat modeling. Automated checks run in the continuous integration and delivery (CI/CD) pipeline: code scanning, dependency and licence checks, secrets detection, infrastructure and container scanning, and dynamic testing. Findings go straight to the developers who own the code, with clear deadlines for fixing them.
Yes. Control 1-6-3 of the Essential Cybersecurity Controls (ECC-2:2024) requires secure coding standards, trusted and licensed sources for development tools and libraries, compliance testing of software against the entity's cybersecurity requirements, secure integration between applications, and review of secure configuration and hardening before launch. Subdomain 2-15 adds controls for external web applications, including a web application firewall, multi-tier architecture and secure protocols such as HTTPS.
Section 3.3.6 of the SAMA Cyber Security Framework requires member organisations to define, approve and implement application security standards, monitor compliance and measure their effectiveness. Development must follow an approved secure SDLC methodology. The standard must cover secure coding, security configuration and logging, access management, segregation of duties with an authorisation matrix, data protection by classification, vulnerability and patch management, backup and recovery, and periodic compliance review.
Static application security testing (SAST) reads source code to find flaws such as injection and weak cryptography before the code runs. Dynamic application security testing (DAST) attacks the running application from outside to find runtime issues such as broken authentication and misconfiguration. Software composition analysis (SCA) checks the open source libraries you depend on for known vulnerabilities and licence problems. A mature pipeline uses all three because each finds issues the others miss.
Reference the OWASP Top 10:2025 for risk awareness. It replaces the 2021 edition and introduces Software Supply Chain Failures and Mishandling of Exceptional Conditions as categories. Use ASVS 5.0.0, released in May 2025, as the testable requirement set, choosing the verification level by application risk. Use OWASP SAMM v2 to measure the maturity of the overall programme and plan the next improvements.
NCA ECC requires remediation based on severity classification and risk, and SAMA CSF 3.3.17 requires defined mitigation timelines per classification. Each organisation sets its own deadline table and must meet it. PCI DSS requirement 6.3.3 gives the one fixed number: critical and high security patches installed within one month of release. Set tighter deadlines for internet-facing and critical systems, and track every exception with an expiry date.
Well-designed gates keep releases moving. Fast scans run on each pull request in minutes, and full scans run nightly or before release. Gates block only new critical and high findings, exposed secrets and dangerous misconfigurations, while existing issues move to a tracked backlog. Developers get precise findings inside their merge requests, which is faster than fixing a penetration test report weeks after release.
Discuss your requirements with Limaz
Tell us which system, control, or requirement you are working on. We’ll come back with a clear next step.