Code Smell 262 - Not Replaced Constants
Yet Another Security Code Smell Because Nobody Ever Reads the Documentation

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.
Search for a command to run...
Yet Another Security Code Smell Because Nobody Ever Reads the Documentation

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.
No comments yet. Be the first to comment.
In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.
The perfect prompt doesn't instruct the model on what it already knows how to do.

Approve the logic once, then let it run the same way forever.

Different stages need different brains.

One Second Brain doesn't scale past one skull.

Style errors double when nobody enforces them.

TL;DR: Ignoring constant replacement leads to severe security risks.
Vulnerable endpoints
Lack of Testing
Documentation Nobody Reads
Enforce constant key replacement
Audit upstream vendors
Automate security checks
Enforce your Documentation with tests
Use invalid defaults to ensure they are always replaced
A major security flaw, PKfail, persisted unnoticed for 12 years, compromising hundreds of devices.
The vulnerability stems from vendors failing to replace a "DO NOT TRUST" Secure Boot master key, a critical step that was neglected despite clear instructions.
This oversight left countless devices open to exploitation, allowing threat actors to bypass security measures and install malicious software.
fn generate_pk() -> String {
"DO NOT TRUST".to_string()
}
// Vendor forgets to replace PK
fn use_default_pk() -> String {
let pk = generate_pk();
pk // "DO NOT TRUST" PK used in production
}
fn generate_pk() -> String {
"DO NOT TRUST".to_string()
// The documentation tells vendors to replace this value
}
fn use_default_pk() -> String {
let pk = generate_pk();
if pk == "DO NOT TRUST" {
panic!("Error: PK must be replaced before use.");
}
pk // Valid PK used in production
}
[X] Automatic
You can detect this smell by checking for default values that must be replaced before deployment.
Tools like static analyzers and manual code reviews help you identify hardcoded or placeholder keys that should be updated.
[X] Intermediate
AI generators might create this smell unless instructed for context-specific security steps.
You must provide clear instructions to ensure proper key replacement.
AI tools can catch this smell with rules that flag placeholder values through testing and reviews.
Ignoring crucial steps in the security process, such as replacing default keys, can lead to severe vulnerabilities.
This long-lasting flaw emphasizes the need for diligent security practices.
Replace all your documentation with acceptance tests.
Code Smells are my opinion.
Photo by Jason Leung on Unsplash
It takes 20 years to build a reputation and a few minutes of cyber-incident to ruin it.
Stephane Nappo
This article is part of the CodeSmell Series.