We are pleased that members of the Software Assurance Forum for Excellence in Code were active participants at the Black Hat Technical Security Conference and have begun to work together to devise new security best practices.

SAFECode members, including giants Adobe and Microsoft, took time to listen to the security community during a brainstorming session about how to produce more secure software over the next decade. Those ideas will be incorporated into white papers and best practices documents.

Not too long ago, most software makers would refuse to admit the presence of security vulnerabilities in their products. Secrecy didn’t make us more secure. We’re glad to see that more companies are talking about real-world security as well as sharing the details.

It is even more encouraging that SAFECode members are willing to learn from one another. Many of these software companies sell products that work with each other’s respective products. Cooperation is necessary if end users’ safety is to be sufficiently protected. Hackers collaborate. We need to do the same.

The more software makers take a full life-cycle approach to security, the better for all of us. Vulnerabilities can propagate down or up the stack, and security is only as strong as the weakest link, whether it’s in operating systems, off-the-shelf applications or custom code.

We hope that SAFECode’s technical committees have learned from the Black Hat experience, and that those suggestions are put to good use.

Develop your master plan
Organizations looking to move to agile development practices—specifically Scrum—are encouraged to bring in trainers, or ScrumMasters, to get them started. This is the shared opinion of the experts interviewed for our special report on Scrum that begins on page 23 of this issue.

But did you know that students need only take a single two-day course, and pay a relatively small fee, to earn the Certified ScrumMaster label?

We understand that the concepts of Scrum are not difficult to grasp and the terminology is not overly confusing. But can anyone really become a master of anything in just a couple of days? We don’t believe so, especially not when organizations depend on those newly minted ScrumMasters to guide their agile practices.

If you’re with an organization moving to agile methodologies like Scrum, we agree that it’s a good practice to bring in an expert. But look beyond the certification to the person’s actual work history. Experience matters. Has he or she led many Scrum teams before? If your organization is doing distributed development, has the ScrumMaster had experience managing agility under those circumstances? What if you need help to bring in a more technical agile process, such as XP, with Scrum? Has he or she done that before?

Our industry is all too quick to hand out certifications, where real-world education and proven work experience seem less important than the ability to pay the testing company for a couple of classes and an exam. One class we found said, “Prior experience with Scrum ‘a plus.’ ” Not even mandated—a plus!! In theory, you could sign up for the class on Monday with no Scrum background, take the class, take a test, write the check and be a Certified ScrumMaster before Friday.

We urge the Scrum Alliance, which oversees this certification, to establish serious software development prerequisites before letting someone take the test and become a Certified ScrumMaster. Require—don’t suggest—that the candidate show he or she has worked for a number of years implementing Scrum in diverse organizations with different development processes. If the certification is to have any real meaning, do the due diligence before issuing that piece of paper.

This way, when organizations looking to get started with Scrum bring in a master to help with the transition, they can have some level of assurance that the person is indeed a master of Scrum, with more than a card or vest patch to prove it.