August 22, 2013 at 12:49 pm
Perhaps its just a figure of speech, but the fixation on firing people for this seems misplaced.
Surely, coding to prevent SQL Injection is a learned skill, like many others.
If a company had rigorous guidelines, training, or quality control initiatives and a programmer stubbornly refused to change coding pratices, then termination makes sense. Otherwise, it seems like it falls into the category of a teachable mistake.
The ultimate responsibility for public errors, incursions, and data loss should rest much higher in the organization.
August 22, 2013 at 3:33 pm
brdudley (8/22/2013)
Perhaps its just a figure of speech, but the fixation on firing people for this seems misplaced.Surely, coding to prevent SQL Injection is a learned skill, like many others.
If a company had rigorous guidelines, training, or quality control initiatives and a programmer stubbornly refused to change coding pratices, then termination makes sense. Otherwise, it seems like it falls into the category of a teachable mistake.
The ultimate responsibility for public errors, incursions, and data loss should rest much higher in the organization.
Obviously there would only be a question of firing if such code got out of the door; trainees and other junior developers are not responsible for what goes out of the door, checks (code reviews as well as testing) are needed that things conform to corporate standards and if they don't training can be given. For more senior people who are new to the shop, QA of their output should include testing for susceptibility to injection during an initial period: that's easy enough to do. They should have had an induction which makes corporate policies and standards clear, and these should be reinforced by seminars from time to time. Even so, if they don't do it during the period when injection checks are being done in QA and then do it afterwards, they aren't going to be fired the first time - but it had better not happen twice. For really senior people (system architects, departmental and divisional chief designers, the person to whom responsibility for security policy design, and others at that level, there should be very harsh words and firing is certainly a possibility if the response to those words indicates the wrong attitude to their responsibilities. But "fire anyone who does it" is , as you suggest, more a figure of speech intended to indicate the seriousness of the problem than a statement of fixed policy; firing a trainee who gets it wrong is just stupidity (firing a trainee who is incapable of learning or just unwilling to learn is a different matter).
Tom
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply