By Donald Firesmith
Software Solutions Division
One of the most important and widely discussed trends within the software testing community is shift left testing, which simply means beginning testing
as early as practical in the lifecycle. What is less widely known, both
inside and outside the testing community, is that testers can employ
four fundamentally-different approaches to shift testing to the left.
Unfortunately, different people commonly use the generic term shift left
to mean different approaches, which can lead to serious
misunderstandings. This blog post explains the importance of shift left
testing and defines each of these four approaches using variants of the
classic V model to illustrate them.
By Tim Palko
Senior Member of the Technical Staff
CERT Cyber Security Solutions Division
The workflow of deploying code is almost as old as code itself. There are many use cases associated with the deployment process, including evaluating resource requirements, designing a production system, provisioning and configuring production servers, and pushing code to name a few. In this blog post I focus on a use case for configuring a remote server with the packages and software necessary to execute your code. This use case is supported by many different and competing technologies, such as Chef, Puppet, Fabric, Ansible, Salt, andForeman, which are just a few of which you are likely to have heard on the path to automation in DevOps. All these technologies have free offerings, leave you with scripts to commit to your repository, and get the job done. This post explores Fabric and Ansible in more depth. To learn more about other infrastructure-as-code solutions, check out Joe Yankel's blog post on Docker or my post on Vagrant.
By Lori Flynn
Member of the Technical Staff
CERT Secure Coding Team
This blog post was co-authored by Will Klieber.
software application installed on a mobile smartphone, whether a new
app or an update, can introduce new, unintentional vulnerabilities or
malicious code. These problems can lead to security challenges for
organizations whose staff uses mobile phones for work. In April 2014, we
published a blog post highlighting DidFail (Droid Intent Data Flow Analysis for Information Leakage), which is a static analysis tool for Android
app sets that addresses data privacy and security issues faced by both
individual smartphone users and organizations. This post highlights
enhancements made to DidFail in late 2014 and an enterprise-level
approach for using the tool.
By Mike Konrad
Software Solutions Divisions
As recent news headlines about Shellshock, Sony, Anthem, and Target have demonstrated, software vulnerabilities are on the rise. The U.S. General Accounting Office in 2013 reported that “operational vulnerabilities have increased 780 percent over the past six years.” These vulnerabilities can be hard and expensive to eradicate, especially if introduced during the design phase. One issue is that design defects exist at a deeper architectural level and thus can be hard to find and address. Although coding-related vulnerabilities are preventable and detectable, until recently scant attention has been paid to vulnerabilities arising from requirements and design defects. In 2014, the IEEE Computer Society Center for Secure Design was established to “shift some of the focus in security from finding bugs to identifying common design flaws—all in the hope that software architects can learn from others’ mistakes.” “We believe that if organizations design secure systems, which avoid such flaws, they can significantly reduce the number and impact of security breaches,” the center states in its report Avoiding the Top 10 Security Design Flaws. On a separate front, a group of researchers from various disciplines within the Carnegie Mellon University Software Engineering Institute recently came together to explore the implications of design-related vulnerabilities and quantify their effects on system cost and quality. This post highlights key issues and findings of our work.
By Todd Waits
Cyber Security Solutions Directorate
This post is the latest installment in a series aimed at helping organizations adopt DevOps.
In a computing system, a context switch occurs when an operating system stores the state of an application thread before stopping the thread and restoring the state of a different (previously stopped) thread so its execution can resume. The overhead incurred by a context switch managing the process of storing and restoring state negatively impacts operating system and application performance. This blog post describes how DevOps ameliorates the negative impacts that "context switching" between projects can have on a software engineering team’s performance.