All of the secure coding tools in the world are no good unless we have good tracking of code quality
and testing.
So once your code is developed the first thing you're going to want to do is you're going to want to
test that code.
Luckily for us there's lots of really great tools to help us test but we break it down into really two
different types of test first.
Or what we're going to call static code analyzers static code analyzers.
Look at your actual code.
They don't run the code.
They just look through the code and they look for standard types of errors that coders often do.
So if you take a look on the screen I've got an example of a static tester and if you take a look it's
a little bit hard to read at the bottom but you'll notice that it doesn't like the way I'm doing a particular
input validation.
And I'll use this as a way to go back and check that to see if maybe I could do it a little bit better.
So there's lots and lots of static code analyzers out there and you just pick the one that works best
for your type of development platform.
The important thing to understand is that it's not running the code it's just reading it.
And based on lots of people's experience it a little bit of logic.
It makes suggestions that you then go back in and change if you really want to test something though
you're going to have to use a dynamic analysis.
In other words run the code a dynamic analysis actually runs the code to look for logic errors to look
for security holes.
You can do things for example try to put really bizarre inputs and I'm not talking about input validation
per se.
What I'm talking about is like typing in sequel commands into the last name field.
Crazy things like this that are known generically as fuzzing and there are actually tools out there
flusters that you can use to actually throw in a lot of well-known hacking type code to see if we can
break your system and that's what it's all about.
So the dynamic analysis actually runs that code dynamic analysis handles things that you could never
deal with a static code analyzer for example do you have a memory leak.
Do you have a problem with the way you're querying the databases.
These things really require a dynamic analysis.
All right so you keep running these tests these tests are run once they're run continuously through
the development process.
But there is a point where you're really starting to think you got your code and that's where we move
into staging.
Staging basically means you want to start creating more and more realistic real world environments to
see how your code does.
So the first test that we normally do is a stress test with a stress test.
What we're doing is we're actually putting the entire system under load.
Can the databases keep up.
Do I get refresh problems with screens.
Do I have good denial of service attack defenses built in or at least up to a certain point to do a
stress test.
We usually use what's known as a sandbox with a sandbox.
What we're doing is where we actually use real servers usually virtual servers and we get everything
up and running if you have a database server separate from your application server.
Everybody's up and running and cooking but it's a completely isolated environment.
You're not actually out in the real world.
You might even be public facing a little bit in some sandbox environments.
After a good stress test within a sandbox you're getting close to saying I think we're getting ready
to put this up into the last stage which is going to be deployment or production.
But before we do that the last step we're doing is called Model verification model verification is the
process where we go back and we go look when we first decided to make this application whatever it is
we had a vision of what it was supposed to be and what it was supposed to do.
That is our model the model verification is that step that goes is this doing what we visualized from
the model.
Now if it's a game it could be things like Well when we shoot the evil robot overlord does he explode
into 25 pieces that are blue or 37 pieces that are red.
If we're setting up a database system error the input screens coming up at the time we expect them to
come up and closing properly.
So we go through this model verification not to necessarily say that it's not working but to make sure
that it's matching the vision the model that we originally chose.
Once we've gone through these steps then the last steps the most interesting and that is production
at this point we're taking things off the sandbox.
We're putting up on public facing servers and we flip the switch and hopefully we make.
I don't know.
Lots of money.