Abstract
Software security is a component of software development that should be integrated throughout its entire development lifecycle, and not simply as an afterthought. If security vulnerabilities are caught early in development, they can be fixed before the software is released in production environments. Furthermore, finding a software vulnerability early in development will warn the programmer and lessen the likelihood of this type of programming error being repeated in other parts of the software project. Using Continuous Integration (CI) for checking for security vulnerabilities every time new code is committed to a repository can alert developers of security flaws almost immediately after they are introduced. Finally, continuous integration tests for security give software developers the option of making the test results public so that users or potential users are given assurance that the software is well tested for security flaws. While there already exists general-purpose continuous integration tools such as Jenkins-CI and GitLab-CI, our tool is primarily focused on integrating third party security testing programs and generating reports on classes of vulnerabilities found in a software project. Our tool performs all tests in a snapshot (stateless) virtual machine to be able to have reproducible tests in an environment similar to the deployment environment. This paper introduces the design and implementation of a tool for security-focused continuous integration. The test cases used demonstrate the ability of the tool to effectively uncover security vulnerabilities even in open source software products such as ImageMagick and a smart grid application, Emoncms.
Highlights
As an increasing amount of critical systems becomes more and more software orientated, the problem of software security vulnerabilities becomes more and more of a concern
While the goal of SFCI is to move the responsibility of software security closer to the main project developers, this does not imply that software penetration testers and security teams have been made obsolete
Discovering new classes of vulnerabilities or improving the accuracy of detecting known classes of vulnerabilities lies within the scope of building penetration testing and dynamic analysis tools, but is outside the scope of the SFCI tool itself
Summary
As an increasing amount of critical systems becomes more and more software orientated, the problem of software security vulnerabilities becomes more and more of a concern. This paper is only concerned with the approach of security by code correctness, as our tool is only useful for presenting information about security vulnerabilities in a developer’s code, as opposed to making them more difficult to exploit or limiting the damage they could cause if they were exploited This is not to say that security by code correctness, or at least security by code improvement, is superior to the other approaches, but rather, that in applications such as the Internet of Things (IoT) and the smart grid, ensuring that programs behave as they are defined [2] (i.e., a smart grid electrical power distribution network should have almost 100% uptime) is critical, if not more, than ensuring that users are only confined to their allocated resources. There exists a wide variety of dynamic software analysis tools and penetration testing tools designed for detecting, and sometimes exploiting, security vulnerabilities within a program These tools cover a wide variety of vulnerabilities including memory safety errors (buffer overflow, use-after-free, etc.), as well as input sanitization issues (SQL injection, command injection, path traversal, etc.).
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
