IEC 62443 mapping (industrial cybersecurity)

IEC 62443 is the international standard series for cybersecurity of industrial automation and control systems (IACS). It is the OT-security counterpart to IEC 61508's functional safety: where 61508 asks "could this system fail in a way that hurts someone?", 62443 asks "could this system be made to fail by an attacker?".

The 62443 series defines Security Levels (SL) 1–4 (analogous to SIL 1–4) and breaks into Parts 1 (concepts), 2 (policies & procedures), 3 (system requirements), and 4 (component requirements). The parts most relevant to a source-code analyzer are:

• 62443-4-1 — Secure product development lifecycle requirements. Process for developing secure IACS components. Includes SI (Secure Implementation), SD (Secure Design), SVV (Security Verification & Validation), DM (Defect Management), SUM (Security Update Management).
• 62443-4-2 — Technical security requirements for IACS components. What the component itself must do. Organised into seven Foundational Requirements (FRs).

plc-st-review is the first OSS PLC linter to ship checks explicitly targeting IEC 62443 concerns (to our knowledge — if you know of another, please open an issue and we'll cite it here). The five new categories cover the slice of 62443 that is actually statically inferable from ST source; the rest of 62443 is runtime / process and remains out of scope.

[!important] Same caveat as the IEC 61508 page: plc-st-review is not a TÜV-certified security tool. This page positions where the engine can contribute to a 62443 secure-development process. Vendor- and integrator-side qualification activities are still required for SL-rated products. The 61508 page has a longer explanation of what TÜV / Tool Class qualification actually means — the same model applies to 62443's security-context Tool Confidence / Qualification expectations.

What this page is — and is not

• It is a mapping from plc-st-review checks to the 62443-4-1 and 62443-4-2 clauses they help satisfy.
• It is honest about scope: most 62443 requirements (FR1 auth, FR2 use control, FR3 system integrity at runtime, FR4 confidentiality of comms, FR5 restricted data flow, FR6 timely response to events, FR7 resource availability) cannot be verified by source-code analysis and live outside any linter. The 62443 mapping has fewer green cells than the PLCopen or MISRA mappings — that's structural, not a gap.
• It is not a claim that running plc-st-review makes a component 62443 SL 1 / SL 2 / SL 3 / SL 4 compliant. SL claims attach to systems and processes, not tools.

62443-4-1 — Secure development lifecycle

62443-4-1 practice	Contributing plc-st-review checks
SD (Secure Design) — SD-3 Defense in depth	POINTER_ARITHMETIC, POINTER_COMPARED, ADDRESS_OF_CONSTANT, MULTI_WRITER_GLOBAL — limit the attack surface and the blast radius of a single defect.
SI (Secure Implementation) — SI-1 Security requirements implementation	HARDCODED_CREDENTIALS, HARDCODED_NETWORK_ENDPOINT — coding practices that prevent leaking secrets / endpoints into version control.
SI (Secure Implementation) — SI-2 Secure coding standards	DEBUG_PRAGMA_IN_PRODUCTION, FORBIDDEN_STATEMENT (gated on GOTO), RECURSIVE_CALL, INDIRECT_RECURSIVE_CALL, MULTIPLE_EXIT_POINTS, UNINITIALIZED_VAR_USED, IMPLICIT_TYPE_CONVERSION, REAL_EQUALITY, BOOL_COMPARISON, ASSIGNMENT_IN_CONDITION — secure-coding hygiene that 62443-4-1 expects every component to follow (the standard explicitly names MISRA, CERT, and equivalent — see MISRA mapping for the rule-level cross-reference).
SVV (Security V&V) — SVV-3 Vulnerability testing — static code analysis	The entire engine — every category, treated as a static-analysis input feeding SVV evidence.
DM (Defect Management) — DM-1 Receiving notifications of security-related issues	(Out of scope — process activity.)
SUM (Security Update Management) — SUM-1 Security update qualification	(Out of scope — process activity.)

62443-4-2 — Component requirements

The seven Foundational Requirements (FRs) of 62443-4-2 cover runtime behaviours of an IACS component. Most are not statically inferable from ST source; the table below covers only the clauses where static analysis genuinely helps.

FR 1 — Identification and authentication control

Component Requirement	Contributing checks
CR 1.5 Authenticator management — credentials shall be stored protected from unauthorised disclosure	HARDCODED_CREDENTIALS — flags secret-named variables initialised with a literal STRING value (the most common variant of stored credential leak).

FR 3 — System integrity

Component Requirement	Contributing checks
CR 3.4 Software and information integrity	UNINITIALIZED_VAR_USED, ASSIGNMENT_IN_CONDITION, ARRAY_INDEX_OUT_OF_BOUNDS, DIVISION_BY_ZERO — defects that allow corrupted or unexpected state to flow into the runtime.
CR 3.5 Input validation	UNVALIDATED_INPUT_USE — VAR_INPUT used as array subscript or divisor with no in-POU relational guard.

FR 4 — Data confidentiality

Component Requirement	Contributing checks
CR 4.1 Information confidentiality at rest	PERSISTENT_PLAINTEXT_SECRET — VAR_GLOBAL PERSISTENT / RETAIN of secret-named values (the data lives in NV memory and is readable through engineering-tool access).

FR 2 / FR 5 / FR 6 / FR 7 — out of scope

These cover use control (access control on the runtime), restricted data flow (network segmentation), timely response to events (audit logging), and resource availability (DoS resistance). They are runtime properties of the component and its host environment, not source-code properties — plc-st-review makes no claim against them.

The five new IEC 62443 checks

All five categories ship at v0.2.2 and are off-by-default in spirit (any project can disable them via disabled_checks), but they run on every push by default:

Category	Severity	Maps to	Doc
HARDCODED_CREDENTIALS	error	62443-4-2 CR 1.5	Check page
HARDCODED_NETWORK_ENDPOINT	warn	62443-4-1 SI-1	Check page
UNVALIDATED_INPUT_USE	info	62443-4-2 CR 3.5	Check page
DEBUG_PRAGMA_IN_PRODUCTION	warn	62443-4-1 SI-2	Check page
PERSISTENT_PLAINTEXT_SECRET	error	62443-4-2 CR 4.1	Check page

The three error / warn categories block CI by default at fail_on_severity: error / warn. UNVALIDATED_INPUT_USE ships at info because its heuristic does not see caller-side validation (see the check's Limits section) — promote it to warn with severity_overrides once your team agrees on the "validate in the POU even if a caller already did" posture.

Suggested severity policy by Security Level

If you are running plc-st-review on a component that will be assessed at an IEC 62443 SL band, a reasonable starting point — adjust to your safety / security case:

Target SL	Suggested policy	Notes
SL 1	fail_on_severity: error	Block on HARDCODED_CREDENTIALS and PERSISTENT_PLAINTEXT_SECRET. UNVALIDATED_INPUT_USE stays advisory.
SL 2	fail_on_severity: warn; promote UNVALIDATED_INPUT_USE to warn	Block on the network-endpoint and debug-pragma findings too.
SL 3	fail_on_severity: warn; promote UNVALIDATED_INPUT_USE to error	Plus add a manual code-review gate for every info finding — your assessor will want documented disposition.
SL 4	All checks error	Combined with a TÜV / TCL-qualified primary toolchain — plc-st-review is a supplementary input at this band, not a primary qualifier.

Limits of this mapping

• The engine has no model of the runtime — no view of authentication paths, no view of which VAR_INPUT is reachable from a network endpoint vs. only from another POU, no view of the cycle-time / task model. The 62443 mapping is necessarily structural ("this shape of code is a known hazard") rather than flow-sensitive ("this specific data path is exploitable").
• The check set is not exhaustive. There are 62443 requirements with no current static analog in the engine (e.g. CR 3.1 communication integrity, CR 2.x use control, FR 6 audit logging). Future versions may add more checks as static heuristics for them become practical.
• The 62443 mapping is vendor-neutral. It does not target any specific vendor's runtime model (CODESYS, TwinCAT, GX Works, etc.). Vendor-specific cybersecurity guidance (e.g. Beckhoff's "TwinCAT 3 Security Guidelines") is a complementary input, not a replacement.

If you are starting a 62443-rated project that wants to use this tool

1. Read the Deterministic by design page — auditability and reproducibility are the same requirements 62443 SVV asks for.
2. Read Check limitations — the documented blind spots are the starting point for your tool-qualification evidence.
3. Read Tuning severities and pin a severity_overrides policy matched to your target SL band.
4. Pin a specific release of the tool (via the npm package or Docker image tag); document the version; treat upgrades as configuration changes subject to your change-control process.
5. Treat this page as a positioning document, not as qualification evidence. Independent tool qualification is the integrator's responsibility.

For everything beyond that, talk to your assessor.