Interviewers: Scott Swigart, Sean Campbell, and Richard Bowler
Interviewee: Michael Howard

Michael Howard

In this interview, Scott Swigart, Sean Campbell, and Richard Bowler interview Michael Howard, a senior security program manager in the Security Engineering team at Microsoft, and an architect of the security-related process improvements at the company. He is the co-author of many security books including the award-winning Writing Secure Code, 19 Deadly Sins of Software Security, The Security Development Lifecycle and Writing Secure Code for Windows Vista.

In this interview, Michael exposes how Microsoft developed the Security Development Lifecycle, which has decreased the number and severity of vulnerabilities in their products. Michael also directly challenges the notion of “many eyeballs” leading to secure code. Highlights include:

• With proprietary software, you can mandate the process.
• Security Development Lifecycle (SDL) was needed because of the pandemic of security vulnerabilities.
• Goals of the SDL.
• Quantifiable results of the SDL
• There’s denial about the vulnerabilities in non-Microsoft products.
• As Microsoft products are hardened, hackers are going after softer targets.
• If you think “many eyeballs” equates to secure code, you’re out of touch with reality.
• Training is key for building secure products.
• The SDL can’t just ban things, it has to provide better alternatives.
• The Microsoft’s central security team has stopped products from shipping because they weren’t secure enough.
• The Bill Gates memo that started it all.
• The next security frontier: social engineering.

Continue reading…

Bookmark this:

A while back, I wrote a blog post about process. In that post I pointed out that closed source companies have the “advantage” of being able to control their development through the application of robust processes surrounding the SDLC. This gives them the ability to carefully manage costs (especially personnel costs) and the quality of a release. In the same post, I wondered how open source projects apply process, since the motivation of a paycheck is missing, and the distributed nature of most open source teams makes process enforcement virtually impossible.

As we’ve continued our investigation, and interviewed several open source people, it has become clear that open source projects have rejected traditional process, and replaced it with a new paradigm: the mailing list. So what is it and how does it work?

Continue reading…

Bookmark this:

Interviewers: Scott Swigart, Richard Bowler, and Sean Campbell
Interviewee: Stormy Peters

Stormy Peters

In this interview, Scott Swigart, Sean Campbell, and Richard Bowler interview Stormy Peters of Open Logic.  Stormy is a frequent keynote speaker on business aspects of open source software at major conferences such as the Open Source Business Conference and the O’Reilly conferences. She has addressed the United Nations, European Union and various U.S. state governments on open source software. Stormy is a co-founder of the non-profit GNOME Foundation, which is based on open source principles to encourage the development of a computing platform, comprised of free software, for use by the general public.

Stormy has impressive experience in the field, and this interview covers a wide range of topics, including:

• When does it makes sense to open-source a given project
• Considerations for open-sourcing a product
• How open source software is supported
• How open source is and isn’t good at fixing bugs
• Choosing between using open or closed source
• How open source software is actually built
• Why open source projects don’t really fragment (fork)
  that much
• The pain of incompatible packages
• And, what OpenLogic does to take pain points away

Continue reading…

Bookmark this:

Here are some key take-aways from the Mark Gross interview:

• Open source projects are sometimes required to carry closed source proprietary code, usually in the form of drivers. This is unpopular, and the open-source community pushes pretty hard for open-source drivers.
• By definition, all kernel code is written by “the community”. It’s also mostly written by corporations. This is not a contradiction.
• Corporate development is critical to the success of open source.
• All code is submitted to the mailing list for approval. Comments are initially about cosmetic issues. Then, they become more substantive.
• Commenting on code is a way to build a reputation. Reputation is important in becoming a maintainer, getting your code added the kernel, and being taken seriously among the community.
• Sometime, there are turf/political battles over sub-systems. Maintainers have broad discretion for what code is approved.
• The mechanisms for secure code are 1) many eyeballs, and 2) quick reaction to vulnerabilities.
• A contributor generally provides bug fixes for the latest version. Back-porting is often not the responsibility of the code author.
• Getting code included in the kernel is a technical process and a political process.
• Some people volunteer to work on the code as a career path, hoping to get hired or sponsored.

Bookmark this:

This week, we posted two solid interviews. The first is with Shawn Burke, a Director in Microsoft’s .NET Developer Platform group. The second is with Mark Gross, an engineer in the Open Source Technology center at Intel Corporation. Shawn really helped to open our eyes to the process that Microsoft uses for building software. You can read distilled highlights from the interview here, but I strongly encourage you to read the entire interview. Mark Gross was equally illuminating regarding Linux kernel development. Again, it was great to peel back the covers and get insight into how the kernel is put together. A distillation is coming, but the full transcript is a good read.

We have many more interviews in the can, and we’ll be posting them up on a regular basis going forward. I’d like to thank everyone in the open and closed source communities for being willing to talk to us. The conversations are helping us greatly as we perform our investigation.

Bookmark this:

Here are some key take-aways from the Shawn Burke interview:

• Microsoft product features come from the bottom-up, and top-down.  Product teams come up with feature ideas, and product execs define broad pillars for the next version.  Features must align to pillars.
• Microsoft doesn’t open source some things like Windows because they’re concerned that code would get included that isn’t licensed properly to be included.
• Community Tech Previews are early builds of a products, released for download.  These are designed to get community involvement and feedback early enough in the product cycle to affect the final product.
• Bugs submitted to Connect go into the same bug database as bugs submitted by internal testers and developers.
• Microsoft thinks hard about what to make extensible because there’s a cost to building extensibility points, and an even larger cost in supporting them.  It’s necessary, but product teams are conservative about it.
• Security is the top priority.  Each feature goes through threat modeling, security review at the code level, static code analysis for security, review by a separate security team, etc.
• Test matrices are massive, and include combinations of supported operating systems, other products, testing around clean install, upgrade, reinstall, etc.
• Performance optimization often happens around key scenarios (cold machine start to first form displayed, for example)

Bookmark this:

Interviewers: Scott Swigart and Richard Bowler

Interviewee: Shawn Burke

Shawn Burke

In this interview, Scott Swigart, interviewed Shawn Burke of Microsoft. Shawn Burke regarding the way software is developed within Microsoft. Shawn is a Director in Microsoft’s .NET Developer Platform group. Currently, Shawn is focused on building shared-source projects focused on new developer technologies from Developer Division. Since he started working at Microsoft in 1997, he’s worked on Visual J++, Windows Forms, and Visual Studio.

This interview covered a wide range of topics some of which follow:

• Eating your own Dogfood at Microsoft
• Product Idea Triage at Microsoft
• The difference between Product Milestones, CTP’s, and RC’s at Microsoft
• Closed Source Cores with Open Source Add-On’s
• Extensibility and Software Development
• Security, Reliability, Scalability and other “ities”…

Continue reading…

Bookmark this:

Interviewers: Scott Swigart and Richard Bowler

Interviewee: Mark Gross

In this interview, Richard Bowler and Scott Swigart interviewed Mark Gross of Intel. Mark Gross is an Engineer in the Open Source Technology center at Intel Corporation. He primarily works on telecommunication computing platform Linux OS support for Intel, along with some additional activities. Mark is also the chair of the power management working group for the Consumer Electronics Linux forum. Mark is a robotics hobbyist and participates in PARTS http://portlandrobotics.org and the occasional Dorkbot get together.

This interview covered a variety of topics some of which follow:

• The role of the Open Source Technology Center at Intel
• Device Drivers and OpenSource distros
• Who determines what gets into the Kernel
• Turf battles with Hibernate
• Security and OpenSource
• Critical Mass and Buy Off in the Open Source community
• Peer Review of Submissions

Continue reading…

Bookmark this: