The SDLA prerequisite for CSA, ICSA and SSA: one process audit, three product schemes

Every ISASecure product certification begins with a certificate that is not about the product. CSA, ICSA and SSA each require a valid ISASecure SDLA certificate before the product evaluation can conclude, and each then reviews the development artifacts of that process for the product in front of it. Suppliers planning more than one product certification ask three questions: what does the process audit settle once, what does every product evaluation look at again, and what happens to the product certificates when the process certificate expires?

The comparison at a glance

The process is examined once

SDLA, Security Development Lifecycle Assurance, certifies a named development organization and a specific, version-controlled version of its documented secure development lifecycle against IEC 62443-4-1. The scheme catalogues the standard's eight practices and 47 requirements as 102 assessable rows, and every row applicable to the declared scope of the process must pass. The evaluation is document review and process audit: the certifier examines the documented process and reviews execution artifacts from products developed under it, chosen from a list the supplier provides. No product is tested.

In ISASecure terms that audit is the SDLPA element, common to every product scheme. A valid SDLA certificate satisfies it for CSA, ICSA and SSA alike, which is what "prerequisite" means in practice: the product certification does not open the process documentation again. The SDLA certificate has established that the organization has a threat-modelling method, a testing regime, a coding standard and a way of receiving and handling vulnerability reports. What remains for the product evaluation is a narrower question.

What each product scheme re-checks

The narrower question is whether the certified process ran for this product and produced what it should have. Each product scheme answers it through its own development-artifact stream, SDA-C in CSA, SDA-IC in ICSA and SDA-S in SSA, and each stream is a view of the same SDLA-312 catalogue.

A CSA evaluation re-checks 77 rows for the component under evaluation. An ICSA evaluation re-checks 93: the same 77 plus the 16 rows that exist only in the IIoT edition of the workbook, ISDLA-312, and that SDLA certification does not require, which is why the ICSA column runs ahead in some practices. SSA has its own subset for systems.

All 17 security-guidelines rows come back per product, because hardening and user guidance are delivered with each product. Eighteen of the 20 verification-and-validation rows come back, since test evidence is product-specific. Defect management, by contrast, sends one SDLA row back to the product evaluation, DM-4, which is also the only SDLA row whose validation depends on the product's capability security level; ICSA adds four IIoT-only rows under this practice. The CSA side of this split is in the SDA-C article; the ICSA side, with the IIoT-specific rows, is in the SDA-IC article.

About two dozen rows only SDLA sees

The catalogue also shows what no product certification ever examines. On Perseus's reading of the SDLA-312 activity columns, 23 rows carry a process-level check but no product-level one, and one further row carries no check on either side: 24 rows in all whose only examination is the SDLA audit.

They cluster where a process lives rather than a product. Nine of the ten defect-management rows are there: the public reporting channel, intake and tracking, review, triage, root-cause analysis, disclosure and periodic review. So are penetration testing, SVV-4, and tester independence, SVV-5, which is why neither ever appears in a product artifact review. Six secure-implementation rows, mostly the content of the coding standard, are there, along with three update-management rows and three security-management rows.

A supplier whose penetration-testing records are thin, or whose vulnerability intake exists only on paper, hears about it in the process audit, not in a product evaluation.

After issuance, the link persists

An SDLA certificate runs to the end of the 36th month after grant when every requirement passed by full evaluation, and to the end of the 12th month when any requirement passed by readiness evaluation. A 36-month certificate is kept by a recertification audit before expiry; a 12-month certificate is extended once every readiness-passed requirement has passed a full evaluation, and the extended certificate runs 36 months from the original grant. The scheme has no surveillance of any kind, and a certificate that lapses restarts as an initial certification. Three consequences follow for the product certificates resting on it.

In CSA and SSA, the certificate covers the certified version and its updates, fixes rather than new features, while the supplier holds an SDLA certificate whose scope includes the product and the product remains in support. On an SDLA lapse, CSA-301 and SSA-301 both prescribe a one-year grace period, after which the product certificate is withdrawn.

In ICSA the same grace period and withdrawal apply, and ICSA-301 adds a condition: the supplier must stay in good standing under the Security Maintenance Audit, whose later rounds are scheduled against SDLA recertification rather than a fixed calendar cycle. ICSA-301 offers the supplier three options for the first audit's timing, two of which are one year after certification and the next SDLA recertification if that falls 9 to 18 months after issuance; after either, later audits fall at each SDLA recertification. The audit re-examines the defect-management and update-management requirements DM-1, DM-2, DM-4 and SUM-5, from practices the SDLA certificate covers at organization level: ICSA watches those requirements on SDLA's clock. The SMA article covers the mechanics.

As an ISASecure certification body, Perseus treats the lapse or termination of an SDLA certificate as a trigger to review every dependent CSA, ICSA and SSA certificate, and withdrawal of those certificates is a possible outcome of that review.

What a certified organization may say about products

The division between process and product certificates carries into marketing. An organization holding an SDLA certificate uses the ISASecure symbol in text form only, with the certificate number; the graphical symbol is reserved for product certifications. It may state that a general class of products is developed under its certified process. It may not assert that a specific product or version was, and once a certificate is lost it may not refer to it at all.

The product-specific claim is what CSA, ICSA and SSA exist to provide. "Our controllers are developed under an ISASecure SDLA-certified process" is a permitted statement about the organization; "Model X version 6.1 is ISASecure certified" is one only a product certificate can support. A product is never "SDLA certified".

Planning: SDLA first, or together

Two sequencing paths are open. The straightforward one is to certify the process first and bring a current SDLA certificate to each product application. The other is the concurrent path the scheme allows: a supplier may apply for SDLA and a product certification together, and artifacts from the product under evaluation may serve both, as execution evidence in the process audit and as product-specific evidence in the artifact stream. Because the product scheme's SDLPA element is satisfied by the SDLA certificate, the product certificate still depends on that certificate being granted.

Four things decide how well the process certificate serves the product certificates.

• Scope. The certified process declares whether it applies to components, systems or both, and which products it covers. A product certification checks that the certificate covers the process actually used for that product: a process declared for components only does not cover a system, nor does a certificate cover a product line outside its declared scope.
• Evaluation method. A single requirement passed by readiness evaluation sets the certificate at 12 months, and that date is what CSA's update path and ICSA's audit schedule read. Because the two methods differ only on the 21 rows where execution artifacts are mandatory, full evaluation there is in effect what earns the 36-month term.
• Renewal. With no surveillance to prompt it, the recertification audit has to be planned by the supplier, and every dependent product certificate needs it to happen before expiry.
• Product list. The SDLA auditor reviews execution artifacts from products of the certifier's choosing. The products you later put through CSA, ICSA or SSA are the natural candidates, and their artifacts do double duty.

Where to go next

The SDLA series index covers what the certificate certifies, the two evaluation methods and the certificate lifecycle. For the product-scheme side of the same link, start with the CSA articles and the ICSA articles.