mailing list archives
Re: A Question of Quality
From: "Yousef Syed" <yousef.syed () gmail com>
Date: Tue, 4 Nov 2008 00:26:06 +0100
Hi Marco, All,
I think the first time that I really got into the whole quality at the
code level was waay back in 2000 when I was involved in my first
Extreme Programming project.
It was mandated that all methods follow Design by Contract
(http://en.wikipedia.org/wiki/Design_by_contract), so we used
Assertions at the beginning and end of each method to validate the pre
and post conditions of any method - on top of that we had Unit Testing
of every method for Correct, Incorrect, Null and Boundary conditions.
It took a little while to get into this, but after a couple of weeks,
it was all second nature. The little extra time in upfront effort &
quality, saved a lot of time later on in bug fixes.
Since then, the technology has moved on. I know that with Struts, you
can use a Validation.xml to validate all inputs.
We can use parametrized Stored procedures to help protect against SQL
I've performed numerous code reviews and security code reviews and
where possible raised the game of the people around me. But that
doesn't change the fact that we appear to have extremely low
expectations for our deliverables unless stipulated in a cast iron
I've worked in many CMMI Level 3 (and some that claimed to be level 5)
where the quality of code being pushed out was appalling - they
delivered to the contract, so nobody cared.
I've worked in places where despite best efforts to put a quality
program in place, it was undermined by management...
However, my point was from a slightly different angle - and perhaps it
is a bad analogy, but I'll make it anyway.
If I go to a car mechanic to get new Tyres, I don't need to TELL the
mechanic to tighten each of the bolts on each wheel, firmly when he
returns the car; it is simply expected - can you imagine the mechanic
saying: "I left them loose because he didn't specifically ask me to
tighten them"! You can find countless other examples in other
industries where a certain level of service is provided without any
need to stipulate it in any contract.
For some reason, our industry isn't anywhere near that, yet. If it
hasn't been written, then it hasn't been said.
Our circumstances are even worse because a lot of our requirements
come from people with little or no knowledge of the technologies
delivering the solution, nor of the potential vulnerabilities that are
being exposed. How many business analysts know what XSS or SQL
injections are? Worse still, it isn't in the interests of the
development team to notify the business analysts, because it just
means more money for them as they call for an RFC in the future -
I know that, as an industry, we are overburdened by large a proportion
of poor developers that have:
a) never been taught quality practices
b) don't know why they are important to follow
c) all they know are the basics of getting a program to function
according to the basic requirements - and that was enough to pass in
d) now they have managers that let them get away to that sloppy
approach in the real world because it isn't in the spec...
We have many managers that have zero technical background and thus no
appreciation of the complexities involved in your average application
- the complexities today are enormous. I've had the pleasure of
working with some extremely good managers, even non-technical managers
that would leave the technical decisions upto the pros. However, we
have far too many that are governed by budget, time and resourcing -
and because they had no appreciation of the technical difficulties,
they planned the time and resources poorly - and the rest of us joined
the death march.
So what can we as industry professionals do to fix this? I'll admit
that a lot of the points mentioned are out of our hands, but I do
think that we need to be raising the level our client's assumed
I think that my initial list was pretty basic and I can think of a few
other items that could be added to it.
Given the amount of time, effort and money that can be saved by doing
things right upfront, in my experience at least, this stuff pays for
itself and that is the way to sell it to the client. Raising the
quality of the people that are producing the solution is a far more
difficult task. I try to get people through my own network, but I'm
not always afforded that luxury.
I believe that as Security Professionals we should be making an effort
as a group to address these short comings and not just as individuals
on our own projects.
2008/11/3 Marco Morana <marco.m.morana () gmail com>
when is the last time that you tried to make this happen for an
organization? The fact that we (security practitioners/consultants
etc) all know what to do to build security in and that this is
documented and vetted by experts and that fact that we have tools and
procedures to use is simply not enough.
You need to look from the perspective of making an assessment first of
the maturity levels and capabilities that organizations have to build
security into their SDLC. Then you can build the case for it. Most of
organizations (at least from my experience) are not like Microsoft
where a Bill Gates memo makes software security happening. You need to
build from the ground up showing the business cases and gaining ground
by partnering with project stakeholders.
Writing Secure Software Blogger
Why, because you are dealing with a people
On Thu, Oct 30, 2008 at 7:55 PM, Yousef Syed <yousef.syed () gmail com> wrote:
Why isn't Quality Assumed?
Why isn't Security Assumed?
Why are these concepts thought of as add ons to Applications and Services?
Why do they need to be specified, when they should be taken for granted?
- Input Validation
- Boundary Conditions
- Encrypt Data as necessary
- Least Privilege Access
- White lists are better than Black lists
I'm approaching this from more of a development/services perspective,
but I'm sure it applies to others. So why should the need for any of
the above genuinely need to be stipulated?
The knowledge is out there.
The tools are out there.
And it doesn't take a huge effort to do - but can save a huge effort
in the future.
I realize that this is a bit of a rant, but I really do believe that
software quality and our expectations surrounding software quality is
worth talking about. During the development life-cycle of a product,
various requirements are stipulated; however, all quality and security
seems to get ignored unless each specific matter has been added to the
Architects and designers don't push back on requirements due to
quality or security issues; but rather, due to the difficulty to
implement it. Code reviews don't through back client code with
username/passwords embedded, but they do throw it back because it
doesn't follow the stipulated coding/naming standards. Testing and
reviewing have their place in this, but I do feel that our focus is
often on some of the wrong things.
I'll leave it there for now so you guys can comment.