Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

What enterprise developers need to know about security and compliance

June 23, 2020
Daniel Domkowski jlien
Related topics:
SecurityCI/CDContainersDevOps

Share:

    One of the luxuries of my job is that I get to speak to and work with a range of IT people employed by U.S. federal and state government agencies. That range includes DevOps engineers, developers, sysadmins, database administrators, and security professionals. Everyone I talk to, even security professionals, says that IT security and compliance can be imprecise, subjective, overwhelming, and variable—especially in the federal government.

    The plethora of policies, laws, and standards can be intimidating in aggregate. Here is a short list:

    • Authorization to Operate (ATO)
    • Federal Information Security Management Act (FISMA)
    • Federal Risk and Authorization Management Program (FedRAMP)
    • Department of Defense Cloud Computing Security Requirements Guide (DoD SRG)
    • 508 Compliance

    Additionally, what it means to be secure or compliant changes from agency to agency, and even between authorizing officers within a single agency, based on a range of factors.

    Many developers ask how newer technologies and behaviors like infrastructure as code (IaC), continuous integration/continuous delivery (CI/CD), containers, and a range of cloud services map to compliance frameworks and federal security laws. As a developer, you're often wondering what your security responsibility is right from the beginning of the software development lifecycle, and you might still be wondering all the way into production. Trust me when I say that you're not the only one who is wondering.

    This article is dedicated to helping you, the developer, understand more of the standards so that less is unknown and variable. The ultimate goal is to make security more precise, establish known responsibility (and gaps in responsibility), and incorporate security into your daily workflow—even when the requirements and how they are interpreted change from project to project.

    Share responsibility and inherit when you can

    Start by establishing that it's not your job to cover it all (or, to say it another way, don't try to boil the ocean). As a developer in the enterprise, it is impossible for you to deliver secure code, configure operating system images, monitor the network, and scan filesystems. If you try to do all of that, you'll spend far less time securing the components that you are responsible for—source code, application dependencies, and testing—and you'll spread yourself too thin.

    The number of platforms and vendors that offer reliable, reputable options for services and products has never been higher, and it is still growing. Infrastructure cloud providers supply resources like compute, network, and storage provision, while software vendors typically provide supported container images for their products.

    The lesson here is to inherit the responsibility that these platforms and vendors assumed for securing an information system. Doing that allows you to check off a significant number of security controls during the ATO process. In the case of patches or responding to security incidents, these providers (not just you) are on the hook to deliver.

    This doesn't mean that you should stop talking to ops and infosec, or that you can place all of the blame on them if an internal, enterprise service they've provided fails. If anything, it means you should work with providers of all types that welcome your collaboration. Intentionally share the responsibility for managing risk. Having an established RACI matrix supports clear communication and assignments of responsibility between developers, operations, and security teams. It enforces the behaviors necessary to generate a successful DevSecOps culture.

    Embrace the world of continuous security

    If you're still doubting when it's important to focus on security in the areas that you are responsible for, then do it all the time. Rather, do it continuously.

    Authors Gene Kim, Nicole Forsgren, and Jez Humble did everyone involved in enterprise software delivery a big favor with their book, Accelerate: Building and Scaling High Performing Technology Organizations, which measures the behaviors that lead to overall organizational performance.  Using data collected from enterprises of all types, the book proves that behaviors like continuous delivery and continuous security lead to a more collaborative culture and overall improved organizational performance. As the book states:

    "Teams that build security into their work also do better at continuous delivery."

    In other words, your organization will reach its goals and deliver better software if you build security into your daily work. Continuously performing security activities and behaviors forces you to learn as you go. It also forces you out of bad behaviors like leaving SSH keys lying around in a repository.

    The DevSecOps Reference Design, authored by the U.S. Department of Defense, is an excellent resource for identifying what security steps to apply during specific software development lifecycle phases to support continuous security. Among other things, the guide recommends:

    • IDE security plugins that scan source code as the developer writes it.
    • Static source code tools that scan code before commits.
    • Source code repository security plugins to check for things like authorization tokens, SSH keys, and passwords.
    • Container registries with security-scanning frameworks that can identify vulnerabilities in container images.
    • Dependency checks for applications using potentially vulnerable open source libraries.
    • Dynamic and interactive tools that scan applications after they've been built.
    • Manual penetration tests that mimic an attacker and might discover vulnerabilities not uncovered by another tool.
    • Continuous monitoring solutions that identify threats at runtime and persist event logging for analysis.

    Get involved in choosing your tools

    Telling a developer to be picky about tools kind of goes without saying. Nevertheless, I've had conversations with too many developers who think that information security is someone else's job. It's everyone's job.

    Because developers are responsible for security, it's important to have a choice about the security products used during the development, building, and testing phases.  In Accelerate, authors Kim, Forsgren, and Humble argue that choosing the correct tool is technical work. "When the tools provided actually make life easier for the engineers who use them, they will adopt them of their own free will."

    Security will be more precise if it's surrounded by the precision of your existing work, such as the security plugins for your favorite IDEs or the scanning tools that are just another component in your CI/CD pipeline. If a tool gives you faster feedback, if it takes less time to use than remediating a vulnerability later in the delivery cycle, then you are more apt to use it. Choose the right tools to incorporate security into your daily work.

    Tech is evolving, but security principles don't

    Container orchestration, serverless platforms, intelligent security tooling, and automated deployments might be changing how we scan for vulnerabilities or patch an application in production, but that doesn't change the fact that security is still more about the process than the products, or that defense-in-depth still reigns supreme for securing an information system. There is a good reason that the National Institute of Standards and Technology's special publication on security controls includes 18 different control families or categories on security. Everything from how you encrypt sensitive information to where you put the fire extinguishers matters to information security. New technologies for cryptography and fire management are surfacing all the time.

    If anything, the best practice is to have an open mind to new technologies that could help you address security concerns in your organization. Automated configuration management, container orchestration, and immutable infrastructure all make it easier to consistently and repeatably configure information systems. IDE security plug-ins and container registry security scanning help to shift security "left" by enabling developers to identify vulnerabilities early rather than during a security review that occurs downstream.

    These tools don't remove the need for standard security principles like security confirmation management and vulnerability scanning; rather, they allow you to focus your attention on where you most need to analyze and manage risk.

    Education is the silver bullet

    Just like software security and delivery, learning should be continuous. New tools help to manage security prevention and response, but attackers are also continuously innovating and learning. There are plentiful resources for delivering software securely, especially in the context of Agile and DevOps. As a former product manager, I can't state enough the power of threat modeling as an exercise for scrum teams to identify potential risks early on in the software development lifecycle.

    I also recommend borrowing what's worked before and replicating outcomes. Read studies about how others have delivered security continuously, like the National Geospatial-Intelligence Agency's success with Red Hat OpenShift. In the case of this program, applications were able to inherit ~90% of their security controls from a hardened CI/CD pipeline and container platform, which not only significantly reduced the developer's responsibility for addressing the controls within their application, but also reduced the time the time to compliance (application ATOs in a single Agile sprint!) Even better, those information security organizations that are pursuing "continuous authorizations" like the US Air Force can really complement and even accelerate their teams that are conducting continuous security in parallel (i.e., all boats rowing in the same direction).

    Reversing the formula, I would also look at security incidents from the past, such as the Apache Struts statement on the Equifax security breach from 2017. Use these past incidents to identify where users and enterprises went wrong. Examine them carefully to understand the consequences of not sharing responsibility and adopting continuous security.

    The recommendations from the Apache statement apply to all types of software delivery, not only to projects using Struts, and certainly not only to Equifax. Everyone is building software today, including government departments and agencies of all types. For software to be delivered continuously and securely, security needs to be everyone's job. This type of behavior leads to lower costs and faster implementation times, which invariably leads to more rapid approvals for compliance and security authorization audits. Let's make it an integral part of each phase of the software development lifecycle.

    Last updated: June 24, 2020

    Recent Posts

    • How to run AI models in cloud development environments

    • How Trilio secures OpenShift virtual machines and containers

    • How to implement observability with Node.js and Llama Stack

    • How to encrypt RHEL images for Azure confidential VMs

    • How to manage RHEL virtual machines with Podman Desktop

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue