acm-header
Sign In

Communications of the ACM

Privacy and security

Toward More Secure Software


Toward More Secure Software, illustration

Last year, the National Institute Standards and Technology (NIST) added 7,937 vulnerabilities to the National Vulnerability Database (NVD), up from 5,174 in 2013. That is approximately 22 per day, or almost one every hour. Of these, 1,912 (24%) were labeled "high severity" and 7,243 (91%) "high" or "medium."7 Simply put, they cannot be ignored.

As I read reports of new vulnerabilities and the risks they enable, I wonder whether it will ever end. Will our software products ever be sufficiently secure that reports such as these are few and far between? Or, will they only become more prevalent as more and more software enters the market, and more dangerous as software increasingly controls network-enabled medical devices and other products that perform life-critical functions?


Comments


Marco Alvarado

As a software developer none of these alternatives give me real solutions.

The first one creates the mentioned colluding problem.

The second one could deviate to a legal requirement. As happens with the car industry, a financial calculation could indicate that it is better not to fix a problem but to pay the fines, "if" somebody exploits the related issue.

However, when choosing from these two alternatives, the liability win by a big margin.

For me, as security specialist, the main problem is not related with liability but with the existing vulnerabilities. Because the legal procedures will run for years while my customer's data is being sacrificed in the wait.

I am a firm believer than the real solution is in the school. Software must be provided a first grade citizenship (with rights and requirements) as the process to build a dam or to make a brain surgery. Anything less than this will always provide low quality products full of security weaknesses.

Because, to create good software is a very specialised and demanding task, requiring good basements and tools. Any person can make insecure software and it is important to differentiate the straw from the gold.


Displaying 1 comment

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.