Security issues with…
1) Open Source (community created) – Open Source Communities don’t always focus on risk analysis. This is a paper tiger since typically FOSS programmers are not paid to care about security as top priority. If compensated properly, they can and will implement proper security procedures. I do not know anyone that views this as “FUN” programming. However the source code can be viewed and therefore fixes can be made by anyone that is paid to do so.
2) Proprietary – Typically proprietary software results in a single point of failure in regard to code being fixed. That singular point of failure is the vendor. All the insane governmental contracting regulations are created to try and prevent that vendor based failure from happening. Much of this is CYA dumping on the vendor in the attempt to create an equitable relationship. Often times this also results in software being unreasonably expensive. These CYA attempts are a smoke screen however because you never really know if the software is secure without the visible code and all its inner workings.
3) Homegrown – If done in house, you have the ability to see all code and do proper vetting procedures. But hiring upper echelon programmers is difficult. The vetting process is one that most programmers are not typically willing to go through just because of basic creative personality characteristics. A top programmer can make more money with less hassle in the business sector.
So I suggest a melding of all three. If you can’t see the code is it ever going to be truly secure? Instead have internal teams focus on proper security vetting. Create good release procedures about security information and adding back working fixes to the FOSS community. And if necessary (typically I see this as a failure of timing) do not release security information until internal teams have created a fix that is ready for the public. Also use those third party outsiders to do security testing of the FOSS products. It doesn’t matter if their source is open or not. They just have to inform you of the vulnerabilities they have found.
I think Government could perform an amazing community service that is a win/win solution for the public by focusing purely on the Customization and Security of FOSS projects with their internal teams. This way they can be suitably vigorous without significantly increasing the barrier of entry to contractors and FOSS communities. And they could save money but not having such convulted contracting procedures.
Also Proprietary companies that help with security processes of risk analysis and risk management and can help supply warranties. After all why would anyone undertake risk without compensation? Otherwise it is an inequitable relationship that cannot be trusted.
Let us not forget the change management aspect of adopting a new methodology. Working with open source code AND open source COMMUNITIES is going to require some serious change management for current government employees. There is a HUGE cultural break because so much in resources is currently used for CYA. We have to retrain them in regards to open processes.
Also recognize with being so integrated with FOSS there may come a time for the project to fork because of security issues. This is extremely difficult and political and must be managed properly. This will require serious training in typical FOSS community culture and processes. For example govt employees should understand the basic stages of FOSS development and the different risks that each stage poses.
We also need to prep FOSS vendors on how to integrate with government processes as well. There is a middle ground here. We need to define it for the barriers to be broken down successfully. We have to be ready to help gently educate them as well (instead of being self absorbed self righteous a$$#&& – you know who you are…)
You can see from the need for security, risk analysis, risk management, and change management that FOSS does not reduce costs. But it can result in better software for the money spent with less flamboyant failures that seem inherent to the current high risk bidding procedures in government.
Some good reference materials: