Security

What Happens When Software Companies Are Liable For Security Vulnerabilities? (techbeacon.com) 221

mikeatTB shares an article from TechRepublic: Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off... Things have been this way for decades, but the status quo might soon be rocked as software takes an increasingly starring role in an expanding range of products whose failure could result in bodily harm and even death. Anything less than such a threat might not be able to budge software engineers into taking greater security precautions. While agile and DevOps are belatedly taking on the problems of creating secure software, the original Agile Manifesto did not acknowledge the threat of vulnerabilities as a problem, but focused on "working software [as] the primary measure of progress..."

"People are doing exactly what they are being incentivized to do," says Joshua Corman, director of the Cyber Statecraft Initiative for the Atlantic Council and a founder of the Rugged Manifesto, a riff on the original Agile Manifesto with a skew toward security. "There is no software liability and there is no standard of care or 'building code' for software, so as a result, there are security holes in your [products] that are allowing attackers to compromise you over and over." Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. End-User License Agreements (EULAs) have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. Experts see that changing, however.

The article suggests incentives for security should be built into the development process -- with one security professional warning that in the future, "legal precedent will likely result in companies absorbing the risk of open source code."
Software

Announcing 'build', Auto-Configuration In 1000 Lines Of Makefile (github.com) 103

Christophe de Dinechin created the XL programming language -- and as descubes he's also Slashdot reader #35,093. Today he shares his latest project, a simple makefile-based build system that he's split from ELFE/XL: Most open-source projects use tools such as autoconf and automake. For C and C++ projects, build is a make-based alternative that offers auto-configuration, build logs, colorization, testing and install targets, in about 1000 lines of makefile. A sample makefile looks like this:

BUILD=./
SOURCES=hello.cpp
PRODUCTS=hello.exe
CONFIG= <stdio.h> <iostream> clearenv libm
TESTS=product
include $(BUILD)rules.mk


Slashdot Top Deals