By Mike Gagliardi,
Software Solutions Division
In Department of Defense (DoD) programs, cooperation among software and system components is critical. A system of systems (SoS) is used to accomplish a number of missions where cooperation among individual systems is critical to providing (new) capabilities that the systems could not provide. SoS capabilities are a major driver in the architecture of the SoS and selection of constituent systems for the SoS. There are additional critical drivers, however, that must be accounted for in the architecture that significantly impact the behavior of the SoS capabilities, as well as the development and sustainment of the SoS and its constituent systems’ architectures. These additional drivers are the quality attributes, such as performance, availability, scalability, security, usability, testability, safety, training, reusability, interoperability, and maintainability. This blog post, the first in a series, introduces the Mission Thread Workshop (MTW), and describes the role that it plays in assisting SoS programs to elicit and refine end-to-end SoS mission threads augmented with quality attribute considerations.
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.
By Julien Delange
Member of the Technical Staff
Mismatched assumptions about hardware, software, and their interactions often result in system problems detected too late in the development lifecycle, which is an expensive and potentially dangerous situation for developers and users of mission- and safety-critical technologies. To address this problem, the Society of Automotive Engineers (SAE) released the aerospace standard AS5506, named theArchitecture Analysis & Design Language (AADL). The AADL standard,defines a modeling notation based on a textual and graphic representation used by development organizations to conduct lightweight, rigorous—yet comparatively inexpensive—analyses of critical real-time factors, such as performance, dependability, security, and data integrity. AADL models capture both software and hardware components, as well as their interactions, including the association of a software process on a processor or the deployment of connection on a bus. The AADL standards committee, led by my colleague, Peter Feiler, who played an instrumental role in the development of AADL, meets regularly with members from around the globe who represent a wide variety of industries, from avionics to aerospace, to discuss evolving elements of the standard and to work together on action items from prior standards meetings. In this post, we present highlights from a series of podcasts that we recorded with Feiler and four members of the standards committee discussing their real-word application and experiences with AADL.
By Douglas C. Schmidt
part of an ongoing effort to keep you informed about our latest work, I
would like to let you know about some recently published SEI technical
reports and notes. These reports highlight the latest work of SEI
technologists in resilience, metrics, sustainment, and software assurance.
This post includes a listing of each report, author(s), and links where
the published reports can be accessed on the SEI website.