Communications of the ACM,
Vol. 58 No. 4, Pages 24-26
10.1145/2736281
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?
1 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
Purchase the Article
Log in
Create a Web Account
If you are an ACM member, Communications subscriber, Digital Library subscriber, or use your institution's subscription, please set up a web account to access premium content and site
features. If you are a SIG member or member of the general public, you may set up a web account to comment on free articles and sign up for email alerts.
![[article image]](https://cacm.acm.org/system/assets/0001/9180/032015_CACMpg25_Toward-More-Secure.large.jpg?1476779475&1426857328 "Toward More Secure Software, illustration")
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.