(ISC)2, an information security certification provider, already has thousands of security professionals accredited under its Certified Information Systems Security Professional (CISSP) programmes. With the launch of the Certified Secure Software Lifecycle (CSSLP) accreditation, however, (ISC)2 hopes to spread the word out to those responsible for designing, building, testing and maintaining applications.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The programme will be based on similar lines to the CISSP course, requiring candidates to have four years practical experience, take an exam, follow a code of ethics, and maintain their skills through continuing education.
"This has been a year in the planning," said John Colley, managing director of (ISC)2 EMEA, "We have built a common body of knowledge which is language independent, and which looks on the whole process of development right from the design stage."
(ISC)2 will now begin licensing training companies to carry out security education for developers, with first registrations for exams expected by next February, and the first exams taking place in June.
Reaction from industry has been positive. Martin Jordan, a principal advisor at KPMG LLP, said: "It's been a long time coming, it's long overdue. There have been other attempts to make this happen, but (ISC)2 will bring to it the same global reach and recognition that it has achieved with the CISSP programme.
He said that in the code reviews that KPMG carries out, software developers were still making many of the same old mistakes. "When we review code, we see common mistakes that can only be made by not following a secure lifecycle," said Jordan.
Those common errors include buffer overruns, stack overflows and running a program with the maximum number of privileges, purely for the convenience of the programmer, he said.
Jordan added that many companies also leave themselves vulnerable by having software developed overseas. "In the price competitive world of offshoring, security doesn't get a very high priority," he said.
Jordan also questioned the value of using code-analysis tools to improve application security. "A lot of people are investing in software products to fix the problem, but that misses the point. Products don't fix it; it is education and process that fix it at the root cause," he said. "There is no point in giving developers a secure coding product if they don't understand the fundamental premise of what they're trying to fix."
According to a survey of 75 universities, the government-funded Cyber Security Knolwedge Transfer Network found that only about 20 percent of honors-degree computing classes devote more than five hours to technical security content during the entirety of the course.
Keeping in mind the conclusions of a survey by independent research company Gartner Inc., -- that 75 per cent of security breaches occur as a result of software flaws -- the KTN made 18 initial recommendations for raising the standard of software, with greater participation from professional bodies and universities, and a requirement for software companies to document their approach to security and make this available for inspection by purchasers.
Nigel Jones, director of the KTN, welcomed the move by (ISC)2. "If it raises the profile of security and gets people to write to a standard, it can only be a good thing." He added that in his discussions with other bodies around the world, there was no single view on what constitutes good practice. "I think that is still work in progress. It will be fascinating to see what is the (ISC)2 syllabus," he said.