It's Bigger than Us
It's about how culture shifts are key to making your products secure.
Properly embracing security in your software supply chain cannot be done without software assurance and software quality. Those commitments require a culture shift. The culture shift is based in the understanding that software weaknesses will be exploited at some time, and that new weaknesses may be discovered at any time.
​
New rules must be built into your software development processes and supply chain to educate developers, testers, contractors, stakeholders, and business professionals that software is "5 parts software quality and 2 parts software security" —and that security is everybody's job.
​
At eruditeMETA, we know that no single tool or program can identify and correct every weakness; several tools working together is the only way. We have combined multiple tools, integrated or taken pointers from the best, and are implementing AI/ML to bridge the gaps.
​
We educate users while covering the largest set of weaknesses possible to expedite the larger understanding that is needed for true security. We know that it is bigger than us.
We are all weak.
For every business and environment, there is a list of common weaknesses, which all decompose into three basic groups:
-
A set of common weaknesses that are easily detected by external software tools/programs.
-
A set of common weaknesses that are difficult to detect with external tools/software.
-
A set of common weaknesses that cannot be detected with external tools/software.
Do not fall into the trap of automatically assuming that these weaknesses are all technical or software-specific issues.
​
One of the biggest risks faced is based on the behavior of internal actors, i.e., employees. That is a security vulnerability that can only be addressed through education and awareness at every level.
Crawl before walk.
If you are ready to take the first steps, they are easy to read, but much harder to do:
-
Turn on your entire set of compiler warning levels, recompile your code, and then discuss and work through the list of identified issues.
-
Follow the step above with a complete set of unit tests to ensure proper functionality of your software.
​
These may seem to be developer-specific in tasks, but that assumption speaks to the larger problem.
​
What must be understood is that discussion and working through the list is the largest hurdle. It requires participation and collaboration.
Shared ownership means not just acknowledging that the business owns those issues, but that business professionals and non-developer stakeholders need to prioritize this work. No one department or group can own this alone.
Gaslight pros.
Security has to be an ongoing commitment. That means a commitment to each other, internally, as well.
There should be rules that everyone must follow and a commitment to doing so.
Rules can be broken into software-specific practices, such as "compiler warnings should not be turned off or ignored," but even those must be enabled by the business owners.
​
"All code checked into the configuration management system or source control must be shown to be free of basic quality defects."
​
That is great for a software rule, but if it is not backed by the business and supporting teams, some percentage of quality and security will be forfeited.
​
Everyone should be prepared to make those internal contracts and stand by them.
Honesty: ON
It's harsh, but it is a quote from NIST and MITRE.
As domain experts, software development companies should already be producing quality and secure code. If they are not, they are not domain experts. Both quality and security need to be built into a product from the beginning and be part of the development culture. Unfortunately, there is a lot of software already developed that needs to be both high quality and secure, but sadly, is neither.
​
The enormity of the problem is visible here:
How can you afford to bring production applications back into development to apply software quality, security, and assurance to them? How can you afford not to?