The Smith Who Found Flaws in Battle
Kirtikara the smith had always worked alone. She forged swords, delivered them to the armoury, and found out they were defective only when a soldier came back injured from battle. The blade had a hairline crack in the blueprint that she had missed. The repair at that stage — retrofit armour, replace weapons, recount losses — cost ten times what fixing the blueprint would have cost. Paschata the late-fixer became Kirtikara's shadow, always arriving after the campaign with a long bill. Darshita the scroll-reader offered to inspect blueprints before construction. Kirtikara was annoyed. Darshita said: "I find one flaw in the scroll for every hundred flaws Paschata finds after the battle."
“A flaw found in the blueprint costs a fraction of a flaw found in battle. Shift security left.”
The Reader of Scrolls
Darshita's method was static analysis. She read blueprints without building anything. She looked for patterns she had memorised from previous campaigns: a blade balanced incorrectly, a hinge that would seize in cold weather, a latch with a known breaking-point under specific pressure. Her pattern library grew with every campaign she read about. She could process a hundred blueprints in the time it took to forge one sword. She worked on the scroll before the first hammer fell. The earlier she worked, the cheaper the fix. Kirtikara learned to give Darshita every new scroll before beginning construction. She was still annoyed by the interruptions. But she admitted that fewer soldiers came back injured.
“SAST (Static Application Security Testing) analyses code without running it, finding vulnerabilities in patterns — SQL injection, hardcoded secrets, weak crypto.”
The Reader Who Could Not See the Running Blade
One campaign, Darshita passed a sword's blueprint. She had checked every pattern. But in battle, the sword behaved unexpectedly: the grip heated beyond tolerance because of how the soldier held it in actual combat — a condition the blueprint could not fully represent. Yodhaka the live-battle tester was brought in. Yodhaka tested the actual sword on an actual field — but a controlled one, not a real campaign. He struck the sword against targets at many angles, tested grip temperature over extended use, and simulated every attack pattern the enemy might use. He found the thermal failure. He also found that under one unusual attack sequence, the tip bent in a way the blueprint's stress model had not captured.
“DAST (Dynamic Application Security Testing) tests the running application — it finds what only manifests at runtime, like certain injection vectors and auth bypass conditions.”
The Two Inspectors Together
Kirtikara asked: "Can I use only Darshita and skip Yodhaka?" Darshita replied: "I find what is in the blueprint. Yodhaka finds what the blueprint did not predict." Kirtikara asked Yodhaka: "Can I use only you?" Yodhaka replied: "I test what was built. If a hundred flaws were in the blueprint, I might find twenty. Darshita finds the other eighty before construction." The two inspectors were not competitors but complements. Static analysis before build; dynamic analysis after build. Some weapons needed both. Critical weapons needed both plus a third: a red-team campaign that actively tried to defeat the weapon using every creative approach Darshita and Yodhaka had not thought of.
“SAST and DAST are complementary. Neither replaces the other. Use both at appropriate stages of the pipeline.”
The Gate Before the Armoury
The kingdom built a mandatory gate between the forge and the armoury: every weapon had to pass both Darshita's scroll-check and Yodhaka's field test before reaching a soldier. Weapons that failed either check were returned to the forge. A smith could not override the gate. A commander could not rush a weapon through without inspection. Some smiths complained the gate slowed them. Kirtikara replied from experience: "Paschata's bill after one campaign costs more than a year of inspections." The gate was not an obstacle to delivery — it was the definition of ready. A weapon that had not been inspected was not a finished weapon, whatever else it appeared to be.
“Security gates in CI/CD are not blockers — they are the definition of done. Failing a security check means the build is not yet complete.”
🪔 Deepak — the lamp of meaning · what this fable means in code
SAST (Static Application Security Testing) analyses source code, bytecode, or binaries without executing them. Tools: Semgrep (custom rules, fast, CI-native), Checkmarx, SonarQube, Bandit (Python), SpotBugs (Java). Best used in PR checks — block merge on critical findings. DAST (Dynamic Application Security Testing) attacks a running application: OWASP ZAP (open source, CI-friendly), Burp Suite (manual + automated). Best used against a staging environment. DAST finds runtime issues: authentication bypass, session fixation, DOM XSS, server misconfigurations. SCA (Software Composition Analysis) is a third category — scanning dependencies for CVEs (Snyk, Dependabot). A mature AppSec pipeline runs SAST and SCA on every PR, DAST against staging on every deployment, and periodic penetration tests for high-value systems. Track MTTR (mean time to remediate) for security findings as a programme health metric.

