@sil - I disagree with this. Maybe because I was a developer and especially, an application architect before, but there is an enormous bonus of having a security guy involved at the early stage of the development of a system.

I agree you can't do a pentest while reading business requirements, but at the very begining of a project, you can help the Project Manager setting a preliminary budget for security. Is the project about exchanging money between 2 big banks or is it a static web intranet site displaying non sensitive data? Even with only the Project Charter, you can for example tell a PM to put money aside to hire 3 full time security specialists or just have the security team test the application before it gets released.

Also, the solution architect and the application architect are setting up the web app framework at the beginning of the development process. Business Analysts are writting test cases before developers start developing.

Also, I often train developers BEFORE they start coding on project specific components. For example, if the team has never implemented SOAP requests between 2 systems, I will:

1) First work with the architect so he can securely set up the framework
2) Then I will train the developers on implementing the solution properly
3) I will help the testers write proper test scripts and test cases
4) Once a module (or even a prototype!) is ready, I will go on an fuzz it, etc. This help me find security problems early in the game so they don't reproduce it many times.
5) At the end of the development, I make sure a vulnerability assessment is done, I review the code, I make sure all test sripts passed, I check the overall solution, etc.

So to me, getting involved at an early stage of project is the key in meeting the project deadline and in implementing good security. In addition, the developers get better and better at this.

What do you guys think?

This in itself is and will always be an issue. We (administrators, engineers, architects) ask for me and when it comes to security, there is only fuzzy math you can use to justify the need for more money. Ever hear a discussion on the ROI of say a firewall. There is no ROI. Ask yourself this question, what is the ROI for the lock you put on your car. The ROI for the alarm you have on your car. What you're left with is "insurance" not a definitive slash sensible numeric value to go by. YOU can say "well I paid 40k for my car" while your insurance company can say "well it's worth 18k" while Edmonds or Carfax can say its worth 30k. What you have are just opinions. What is your car worth to you? Would it be safe to say that your car is worth its price and the cost of your salary if you couldn't drive yourself to work?



This is the failure: "have the security team test the application before it gets released" What about having the guidelines beforehand and testing it all throughout the development phase. For example, phase1: "It sends IM's, make sure no tainting (fault injection) can be done... During phase two, programmer goes through his code checking for buggy code, buggy calls (malloc, strcpy, etc). All the way throughout the phase ESPECIALLY during the initiation phase it needs to be done. Many pentesters aren't programmers and many programmers aren't pentesters. At the end of the day, the initial coding team will understand how a process works, why it does what it does. They need to be more vigilant about calls, procedures, etc. You don't wait until pre-release to test it otherwise what you may end up doing is having to go back through ALL of the code. On some systems this is extremely time consuming and we know in business, time is money.


This is great for new applications but for existing applications it makes little difference as stated before, do you think they'd rather focus on the new release or spend money on an old and buggy one.


We're in complete agreement here about beginning as early on as possible however, the subject for this thread is "to be a professional web-application pentester?" not "to be a professional web-application security coder?"

As a pentester, I don't really care if someone followed the SDLC. This is of little importance to me in fact, I hope they DIDN'T follow any SDLC as it makes my job a heck of a lot easier. As a "secure web application developer" this is quite a completely different story. If I had to play an "application security researcher" then its again, another story. However, risk analysis trumps all of these arguments from both me and you. For example, if whatever application we're talking about resides behind say a private network, do you (as a company) want to spend *that* much money worrying about someone potentially running perl -e 'print "%80x. :x40;' locally (remember I said its in a private network). The answer is low so a manager will minimize this risk often accepting it.

PM: "The odds of this happening are phenomenally low"
SecurityProfessional: "The reality is, if a client side exploit hit the machine its vulnerable"
PM: "What MS/Apple/etc., do with their security is one thing. We can't worry about OUR security because of their INSECURITY"

Ad-nauseum ... It's a nice methodology to want to follow however, most companies are driven by "right here right now... get it done!" where security is a secondary concern (if even that). So it's not that I disagree with you, I don't agree that this is a "pentester's" role per se. At least not in regards to the initial post.

Lastly, NO NO NO I don't mean to sound rude/argumentative, in fact, I'm just in a thinkative state Before someone says... "what an ass"

Ok, I agree with you guys. "pentest" was the topic of this thread, but the focus was "learning PHP"! 

I really like this site! 

Well this is certainly an intense discussion and one of which I have thoroughly enjoyed reading. 

@Sil – This is my favourite comment of the whole discussion being a Junior pen tester myself :

"As a pentester, I don't really care if someone followed the SDLC. This is of little importance to me in fact, I hope they DIDN'T follow any SDLC as it makes my job a heck of a lot easier"