What Is
DevSecOps?

Learn how DevSecOps in embedded systems development addresses security from the start, for faster innovation and deployment along with protection against cyberthreats.

 

What Is DevSecOps?

DevSecOps is a development approach that addresses today’s increasing security concerns within the development cycle. Cybersecurity is a never-ending race to manage risk to organizations, applications, data, and operations. Security organizations face pressure from two forces:

  1. The speed at which businesses must innovate, build, and release solutions has increased exponentially as market pressures have driven organizations to adopt DevOps methodologies that streamline their entire development and release cycles.
  2. The sophistication and volume of cyberthreats has risen dramatically, with devastating consequences from data breaches, ransomware, countless strains of malware, and other threats.
Figure 1: DevSecOps adds security to familiar DevOps practices

Security teams are rethinking their traditional risk management approaches and creating dynamic, automated ways of integrating security testing and validation into the product lifecycle. DevSecOps has emerged as a fundamental strategy.

How Is It Different from DevOps?

The DevSecOps process evolved from DevOps, which combined software development and operations into a unified process with a cyclical flow, automating tasks and bringing consistency and structure to code development. When it became apparent that security concerns could not be addressed as add-ons at later stages, the DevSecOps approach emerged, incorporating security from the earliest planning stage and carrying it through post-deployment.

The Changing Security Landscape

The security landscape is constantly changing, shaped by several factors:

  • Sophistication of threats: The days of easily identified malware signatures are long gone. Malware is now homomorphic or even encrypted altogether, enabling it to proliferate undetected across devices. Unmonitored hardware devices that are internet-enabled allow access points and lateral movement. Sophisticated threat actors have had access to considerable money to develop highly damaging yet practically undetectable attacks.
  • Volume of threats: Cyberattacks are big business. Countless individuals and organizations, including nation states, have incentive to launch ransomware, steal identities, and breach data stores. Internet-connected devices are under constant siege by automated tools that scan for known vulnerabilities.
  • Scarcity of cybersecurity resources: People with the full skill sets for cybersecurity and security engineering are comparatively rare. Organizations often struggle to retain staff and talent to adequately protect their resources. Developers and engineering teams in particular need to understand the implications of security and be empowered to design it into their products.
  • DevOps methodologies: As the product lifecycle has shifted left to embrace DevOps, so have security efforts. Just a few years ago it was possible to run a product through security validation and then reengineer components as necessary. Now, both overarching security needs and the automation-first approach to product release require integrated security validation.

DevSecOps in the Embedded Systems World

Security teams face several challenges as they set up security engineering and DevSecOps integrations in their organizations, including changing team culture, avoiding hardware dependencies, and learning new toolsets and security development skills.

Culture

Traditional security efforts usually look more like audits than engineering efforts. Security teams have long used checklists and hard requirements to evaluate products against security standards. While this approach does give developers direction for security by design, it is difficult to retain staff with the required hardware and embedded systems know-how.

An even bigger challenge is posed by the need to use automation to evaluate the security of embedded systems. This requires tool development, DevOps expertise, and, often, the ability to develop code. Team members need to be trained in the latest capabilities, and some may need additional programming expertise to keep up with their DevOps counterparts. When security teams can make this shift, however, the results are powerful.

The transition to DevSecOps practices can be initially challenging but ultimately powerful for teams.

Hardware Dependency

Most hardware vendors implement security capabilities that should be leveraged by developers and tested by security teams, but they are often proprietary and unique to each platform. Secure Boot, for example, exists in many different implementations, such as Intel® TXT/tboot and U-Boot. It is challenging to create automation that handles their differences.

Security Patterns

How Can Wind River Help?

The Wind River DevSecOps Environment

Wind River® has more experience in agile development in the embedded systems world than any other organization. We pioneered the process for the development of our own products. Our Professional Services team can help your organization take the leap to DevSecOps with best practices for making the most effective use of our cutting-edge development tools.

Security by Design

Strong security begins before a single line of code is written. It starts with design, ensuring that best-practice security principles are being implemented as early as possible. This is especially important for automated security in a DevSecOps world, because these security principles will inform the automation and vulnerability measurements that should be implemented by CI/CD pipelines.

Wind River has partnered with many hardware vendors, including Intel, NXP, and Xilinx/AMD, to enable developers to take advantage of security capabilities and best practices.

A variety of Wind River products support teams embracing DevSecOps practices.

Security Through Design

All too often, security is considered, at best, a phase of the product lifecycle. Perhaps strong security requirements were established early but are not evaluated until late in the development process. Or a security audit is performed just before release, at which point real-time fixes are prohibitively expensive and are scheduled for a future release.

The promise of DevSecOps is to measure security throughout the design-and-release cycle. By leveraging platforms such as Wind River Studio, teams can effect this promise. Studio provides a holistic platform for development, deployment, operations, and servicing edge systems. Once systems are managed in this way, security automation across the lifecycle becomes possible.

A typical DevSecOps environment is represented in Figure 2:

typical DevSecOps environment
Figure 2. A typical DevSecOps environment

This diagram highlights several assets of the DevSecOps environment that need to be secured, including:

  • The repositories
    • Code, local artifact, and released artifact repositories
  • The software components
    • IDE, repos, development, and test components
  • The build tools themselves:
    • Compilers and linkers
  • The connectivity between the components
  • The configuration of each component
  • The storage elements of the components, for both on-premises and cloud-based environments
  • The event logs of all components

One asset not shown is that of the hardware security module (HSM). The HSM is a physical computing device that safeguards and manages digital keys and performs encryption and decryption functions for digital signatures, strong authentication, and other cryptographic functions.

To determine the vulnerabilities, we can start with a definition: “The term information security means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction….” These unauthorized events can be attacks on the DevSecOps system.

Figure 3 identifies the assets that are vulnerable during each unauthorized event. This list is foundational for determining the security implementations required to protect each asset.

Multiple technologies are brought together to secure a DevSecOps environment. The capabilities of each are shown in Figure 4.

Types of attacks
Figure 3. Types of attacks from which each asset must be protected


technologies to mitigate attacks
Figure 4. Capabilities of technologies to mitigate identified attacks

Security and Compliance

Wind River offers automated security and compliance scanning designed especially for complex, embedded software systems, to help development teams identify and prioritize high-risk vulnerabilities. This scanning service uses the Common Vulnerabilities and Exposures (CVEs) database to identify risks and vulnerabilities in applications and open source packages.

Wind River provides expert guidance on CVE mitigation, including necessary recommendations for backporting, validation, and testing patches before applying them. This ensures that your application is remaining current in terms of security requirements — and is doing so with stability and continuity.

DevSecOps with Wind River Products

Wind River Studio

Studio delivers a complete lifecycle management platform that enables development teams to accelerate building, testing, and deploying on the edge. Studio supports full cloud-native platforms as well as end-to-end visibility of development states across CI/CD workflows. By empowering DevOps teams to achieve high levels of automation, Studio creates real opportunities for organizations to implement security automation. Studio supports automation triggering and digital feedback loops that not only raise the bar for development automation but support security integrations as well.

Studio also enables development and security teams to collaborate through a single-pane-of-glass interface, ensuring that security validation is never lost along the product development lifecycle. Artifacts can be captured within Studio and preserved for archival purposes and reuse.

» Learn More
Wind River Products
RTOS

DevSecOps automation relies on adequate tooling. The Studio industry-leading real-time operating system (RTOS), powered by VxWorks®, offers a platform for instrumentation, along with native support for third-party security tools. VxWorks supports DevOps pipeline development and CI/CD models through Studio.

VxWorks also provides built-in security capabilities such as cryptographic services and access controls that can be evaluated through automation. This ensures that developers are using these security capabilities to their fullest.

» Learn More
LINUX OS

The Studio Linux operating system, powered by Wind River Linux, offers DevSecOps engineers the power of open source and a common Linux platform to implement security automation. It supports application containerization and isolation, enabling security teams to create security validation on a more granular level. It also provides strong access controls and separation of duties that can be measured through automated assessment.

Like VxWorks, Wind River Linux supports DevOps pipeline development and CI/CD models through Studio. By developing on an end-to-end platform, DevSecOps teams can perform integrity monitoring across the product lifecycle, from prototype to production.

» Learn More
SIMULATION

Hardware dependencies, as noted above, can be a challenge to teams that want to implement DevSecOps practices. The Studio full-system simulator, powered by Wind River Simics®, eliminates this dependency. Simics can replicate the functionality of many kinds of hardware and operating systems, allowing security teams to develop automated security testing and validation more easily.

For example, teams using Simics can show how a piece of software will respond to different types of security threats. Once your developers have created a model of a system in Simics, they can simulate many different security scenarios, such as data breaches or malware attacks. Development teams don’t have to spend time and expenses in setting up physical development labs, and security teams get an advance look at how the hardware deployment will react under threat. The result is higher-quality code that’s easier to protect, because it’s already been tested under many different scenarios.

» Learn More