Only trying to find and fix software vulnerabilities one at a time will not succeed in the long term. It’s necessary, but future changes might re-introduce other vulnerabilities. So, also apply the general principles of secure-by-design and secure-by-default.
As always, if a system is to be secure in the real world, it must be:
Secure-by-design: Design the software to be secure from the outset.
For example, limit its attack surface and apply defense-in-depth [FiveEyes2026].
Ensure that security checks run where attackers can’t bypass them (e.g., on the server, not only in the client, if an attacker can control a client). See OWASP ASVS 5.0 requirements V2.2.2 and V8.3.1 for their discussion on input validation and authorization [OWASP-ASVS5].
Secure-by-default: Release the software so that it’s secure by default during installation.
Most users install the unchanged default, so the default security is the security of most installations.
A “hardening guide” that users must apply after installation indicates insecure defaults; those steps should have been applied before release.
If necessary, provide a “loosening guide” explaining how to disable security mechanisms in special cases, including the risks involved.
Secure-by-design and secure-by-default “must become standard practice – not an aspiration” [FiveEyes2026].
Quiz
Q1. What does “secure-by-default” mean, per the material?
Security features exist but must be manually enabled after reading a guide
The software is secure in its default installation, without extra hardening steps
The software’s entire source code is kept fully confidential
The software updates itself automatically, without any user consent
Finding and Fixing Vulnerabilities Using AI