A lot of software today is made up of many pieces brought together, and
some of those could've been pieces written by somebody else, either
under contract or something that was just available and we were able to
pick up and use. Well that, of course, means we should also do some
software composition analysis to make sure we're not using some
software illegally.
However, verified secure software is important.
There's a lot of open‑source software products out
there, and a lot of these are really, really good.
There's a lot of advantages to open source and the fact
that we've had the ability to look at it,
examine it, and many people have collaborated on it.
But of course, it also has disadvantages in that we hope
that someone actually did test it.
It could well be that everybody thought somebody else was testing it,
but in the end, nobody was. We have to know whether or not that
open‑source module we're going to use actually came from a trusted
supplier. Was it a trusted source or was it someone who was giving
something away because it had some type of, should we say, Trojan or bad
code buried in it, maybe to do surveillance and so on? Was it truly
thoroughly tested? And this is something that we should also make sure we
ourselves verify that it was tested, not just that we take somebody
else's word for it.
A lot of what we use is related to application program interfaces. And
certainly, they are an important part of our construction today,
allowing the interface between different modules and different programs.
And one of the things we can do to help to ensure that we have a secure
program is to have a library of APIs that we know are trusted, and that
means also tested.
We should have standards and coding standards that prohibit the use
of untested or unknown APIs. One example of this we can see here, IT
World Canada, is that malicious modules found in the NPM library
were downloaded thousands of times, and this is something that means
that many people,
thousands, actually used these modules that were malicious and
didn't realize that. If we use proprietary software,
something was written by a large software house, for example,
that often has some really good advantages when it comes to time of
delivery, and they provide some support for it and so on.
But we don't see what it does inside.
We can't do in‑depth testing. We can do black box, DAST,
dynamic application security tests, but we don't see whether or not the code
that's behind that is reliable, or is it full of maybe some type of buffer
overflows and so on? We should make sure that any time that we've used a product
that we've purchased that we keep up to date with the various patches and that
those patches truly were signed and came from that vendor and they weren't some
type of malicious patch.
Now this is where we can worry a little bit. We've seen more than once where
patches that came out weren't actually working correctly.
And so it's sort of a case where sometimes you wonder if maybe I should wait
a day or two before I roll out the patch to see if somebody else has had a
problem or the vendor realizes an issue with it.
We can buy programs that have an incredibly good
software security built into them.
That's the native security in that product, but we've seen
a number of cases where that security has been disabled or
isn't functioning correctly.
Proper configuration is important there,
but also to have protection in case of vendor bankruptcy
with escrow so that if I bought a product,
for example, that I'm going to use from a nice little
software house that has written a really good product we can
use, but I don't have the source code.
And yet, sometime in the future, we may have a problem, we need to fix it,
update it, and we find out the software house that
wrote it has gone out of business.
He's become a ski instructor now in Colorado.
And so, we don't have any way to maintain that program.
So we want to have the source code in escrow with a trusted
third party so I could get access to it if I need it, at least
to maintain it for my own purposes.
In summary, software is at the front line of the organization.
It provides the interface to the outside world, as well
as support for business functions.
So our whole purpose of testing here is to make sure that that software
is secure and has the required levels of performance.