Detection Rules
LadderScan checks your PLC code against these security and safety rules.
Basic Safety
Detects WHILE or FOR loops where the loop variable is never modified, causing the PLC to hang indefinitely. This can halt all control logic and create dangerous conditions.
Example (Bad)
Fix
Detects when an emergency stop input is declared but never checked in the control logic. E-stops must always be able to halt equipment regardless of program state.
Example (Bad)
Fix
Detects safety-critical outputs (valves, brakes) that default to TRUE (open/disengaged). Safety devices should fail to the safe state (closed/engaged) on power loss.
Example (Bad)
Fix
Detects outputs that are set TRUE but never set FALSE. This can cause actuators to remain energized indefinitely, leading to equipment damage or safety hazards.
Example (Bad)
Fix
Timing & State
Detects TON/TOF timers that are enabled but never reset. This can cause timing logic to malfunction on subsequent cycles.
Example (Bad)
Fix
Detects circular wait conditions where two or more operations wait for each other, causing the system to hang.
Example (Bad)
Detects state machines without timeout handling or error states. If an expected event never occurs, the machine stays stuck indefinitely.
Example (Bad)
Fix
Detects outputs that initialize to unsafe states on PLC startup or after a power cycle. All safety-critical outputs should default to safe state.
Example (Bad)
Fix
Data Integrity
Detects division operations without checking if the divisor could be zero, which causes runtime faults on most PLCs.
Example (Bad)
Fix
Detects array access using variables without bounds checking. Out-of-range access can corrupt memory or crash the PLC.
Example (Bad)
Fix
Detects integer variables that are incremented without overflow protection. INT values wrap at 32767, causing counters to reset unexpectedly.
Example (Bad)
Fix
Detects local variables that are read before being assigned a value. Uninitialized variables may contain arbitrary data, leading to unpredictable behavior in safety-critical systems.
Example (Bad)
Fix
Detects CASE statements without an ELSE default branch. Unhandled selector values may leave outputs in undefined states. Severity bumps to Critical when the selector is a state machine variable.
Example (Bad)
Fix
Input & Validation
Detects HMI or external inputs used directly without range validation. Malicious or erroneous values could cause unsafe operation.
Example (Bad)
Fix
Detects setpoints assigned from external sources without range validation. Out-of-range values could damage equipment or product.
Example (Bad)
Fix
Detects FOR loops with variable end bounds that are not validated, and WHILE loops with unbounded conditions. Unchecked loop bounds from external inputs could cause millions of iterations, exceeding scan time.
Example (Bad)
Fix
Detects magic numbers used for safety-critical comparisons. Hardcoded values are hard to maintain and audit.
Example (Bad)
Fix
Detects setpoints that can change instantly without ramp limiting. Rapid changes can cause equipment damage, thermal shock, or process upsets.
Example (Bad)
Fix
Process Control
Detects watchdog timers that are declared but never refreshed/kicked. If the watchdog expires, the PLC may reset unexpectedly, causing process disruption.
Example (Bad)
Fix
Detects PID controllers without integrator anti-windup protection. The integral term can accumulate unbounded, causing large overshoots when the process recovers.
Example (Bad)
Fix
Detects batch or sequence operations without a maximum duration timeout. A hung process step could run indefinitely.
Example (Bad)
Fix
Detects sensor inputs that are used without range checking or fault detection. Bad sensor readings can cause incorrect control actions.
Example (Bad)
Fix
Detects alarms that are disabled or suppressed without an automatic timeout to re-enable them. Suppressed alarms can mask real problems.
Example (Bad)
Fix
Safety Interlocks
Detects programs that read inputs from other programs without proper interlock variables to coordinate execution.
Detects when maintenance or service modes can disable safety functions without proper authorization, timeout, or logging.
Example (Bad)
Fix
Detects outputs that can be forced/overridden without timeout protection or audit logging. Forced outputs can bypass all safety logic.
Example (Bad)
Fix
Detects when the same variable is modified in multiple independent IF blocks, which can cause unpredictable behavior depending on scan timing.
Example (Bad)
Fix
Detects critical safety functions that rely on a single sensor or input without redundancy. A sensor failure could cause unsafe operation.
Example (Bad)
Fix
Communication & Monitoring
Detects commands received from network/HMI that are used directly without validation or authorization checks. Malicious commands could compromise safety.
Example (Bad)
Fix
Detects remote connections that are assumed alive without heartbeat or timeout verification. A lost connection could leave the system in an unsafe state.
Example (Bad)
Fix
Detects direct and indirect recursive function calls. PLCs have fixed stack sizes — recursion will cause stack overflow and controller crash. Checks both direct self-calls and call graph cycles.
Example (Bad)
Fix
Security
Detects passwords, API keys, or authentication tokens embedded directly in PLC code. Attackers can extract these from compiled programs or project files.
Example (Bad)
Fix
Detects protected values (calibration, limits, passwords) being modified without checking user access level. Operators could modify supervisor-only settings.
Example (Bad)
Fix
Detects critical operations (E-stop, setpoint changes, mode changes) that are not logged to an audit trail. Required for regulatory compliance and incident investigation.
Example (Bad)
Fix
Code Quality
Detects code that can never execute due to always-true/false conditions or missing state transitions. May indicate logic errors.
Example (Bad)
Detects VAR_OUTPUT variables that are declared but never assigned a value. The output will have an undefined state.
Example (Bad)
Cross-File Analysis
Detects when multiple programs write to the same output variable. This causes unpredictable behavior as one program overrides another.
Detects programs that depend on each other's outputs, creating a circular reference that makes execution order matter unpredictably.