, ,

Editor’s Note: This is an excerpt from Mark Troester’s upcoming book, ‘Good Component Practice‘.

CHAPTER 2: Quick Start your GCP efforts

When you’re just starting out with GCP, where should you focus your efforts?

As with any significant initiative, it’s critical to show short-term success. When you’re dealing with competing projects, it’s important to have proven results. So where is the sweet spot, so to speak, to successfully introduce a new process and demonstrate immediate value?

There are three major initiatives with GCP; empowering developers to make better component choices, guiding good component choice, and mitigation of poor component choices within existing applications.

With this end in mind, here are our goals for overall implementation of good component practice:

  • Understand and quantify existing exposure
  • Deliver optimal value quickly
  • Lower barriers to broader organizational adoption
  • Build software with less inherent risk
  • Implement approach that will increase value over time

In this chapter we’ll unpack a suggested approach and share our philosophy on how best to achieve these goals. After completing this Quick Start effort, you’ll have a model to better manage components across the enterprise, not in theory, but in practice. You’ll have identified what components are in use, created a “map” of where they are are used, determined your real exposure, and acknowledged or addressed vulnerabilities.

Component Management Implementation Philosophy: Iterate & Expand

Since GCP will manage, guide and enforce the component supply chain for your applications, GCP must fit smoothly into your environment. To start, you need to think about how your applications are built and deployed today.

  • How do developers choose components?
  • Where do the components come from?
  • How are applications built?
  • Where are they built?
  • Who manages the build process?
  • How does an application move from build to production.

Keeping this context in mind will help ensure that your GCP approach fits well with your development methodology – leading to greater adoption and success.

Start simple, iterate and improve.  Incremental change is the key to a successful effort. It’s best to leverage an approach to management/governance where you iterate over time, advancing incrementally. This goes double for policy creation – even if you start with default or generic policies that provide a foundation on component usage, you will likely have to tune the policies over time to achieve an optimal balance.

Not all applications are equal in regards to risk and not all policies are applicable to all applications.  Starting with an iron-fisted policy applied to all applications is the quickest way to failure.

If you iterate, you can start with your greatest common denominator policies in “audit” mode vs. “enforcement” mode. In audit mode, policies are set to manage risk based on your organization’s risk tolerance. Audit mode can also be considered as collection or inventory mode.  It’s a soft shoe approach; once you feel good about the policy design, you can start turning on enforcement actions (e.g., stop builds, stop promotion to production, etc.) without the resistance you’d get by jumping in head first with too many policies. Over time, policies can be adjusted to lower risk issues and improve code quality.

The iterative process of policy tuning, enabling lifecycle stage enforcement per policy, and early issue notification gives an organization unprecedented control over component risk without creating the traditional antagonistic relationship between governance and efficient software construction.

Iterate and Improve

For most organizations the “big bang” approach – where all teams, all individuals, all departments, and all applications are introduced to component management at the same time – is not feasible. GCP is. Like other technology or policy rollouts, it makes sense to start small and expand over time.

The nice part about good component management is that you can start with your critical applications. That’s right, applications in production that are vital to your organization can set the basis for your effort. It is often easier to see the direction for the future by understanding the mistakes of the past. The technology that you use to support your GCP should be non-invasive to an application’s performance & behavior. There is no need to start with non-core applications since you aren’t introducing additional risk by using component management.

Start with a small team. Start with your key applications(s). And after your initial success: expand.  Before figuring out how to expand, we should understand the definition of initial success.  Initial success would be:

  • Several key applications have been analyzed
  • Visibility into component usage and risk
  • Initial policy tuning performed with product owners
  • Understanding where components originate from
  • Understanding of initial enforcement strategy
  • Understanding of how policy will affect component choice and mitigation

At this time, you have a good understanding of components in use and their associated risk. Here are some suggestions for expansion points:

  • Manage applications in development first/then use component lifecycle management to manage or clean apps already in production (or vice versa).
  • Add more applications.
  • Add more developers.
  • Engage more security personnel and architects.
  • Gradually expand your governance focus. For instance, it could be that you are initially driven to manage security. So get your security team involved first, then expand to licensing (legal/compliance team), then quality (architecture).
  • Add different component types. In addition to your open source components, expand your component management approach to other 3rd party and custom components.
  • Expand use of policy-based governance to help teams adhere to project defined best practices outside the scope of corporate component policy.

Getting Started

For this Quick Start example, we will focus our model effort on key applications that are 1) under active development and for 2) new applications where the development process has just begun. Our examples will be tailored to these two scenarios.

GCP is structured around these four tasks, which we’ll provide detail around:

  • Building an Inventory
  • Determining Threat Exposure
  • Prevent Vulnerabilities and Fix Flaws
  • Iterate and Fine Tune

Building an Inventory

Since we’ve zeroed in on two areas of the supply chain, it’s time to identify what’s currently in use in the development lifecycle as well as what components you will or should use for new apps in the pipeline.

Your approach should consider the following factors:

  • Automation: To reduce the strain on your development and security resources, your inventory capability must be automated.
  • Accuracy: To ensure that you are making decisions on good information, your approach must produce an accurate accounting of your inventory. You should be able to accurately identify components that have been altered.
  • Timeliness: You’ll have greater success if the inventory can be created “instantaneously” when developers choose components, when components enter your environment, or when the composition of your application changes. The process must fit into the development lifecycle naturally, or it won’t be effective. 
  • Threat aware: Researchers are constantly finding new flaws.  The inventory must be constantly monitored for new threats and have automated notification of where the new threat exists in your applications.
  • Contextually rich: Make sure your inventory provides context that spans security, licensing AND quality information.
  • Dependency Aware: Assessing the entire inventory (locally defined dependencies as well as transitive dependencies) will highlight relationships between components and decrease time while troubleshooting.
  • Multi-level: Your inventory analysis should support various levels of activity to include but aren’t limited to: download activity, repository inventory and application inventory.
  • Integrated throughout the lifecycle: Inventory efforts should support the entire development lifecycle with information integrated into the development tools (rather than at a single point, as is the case with scanning technology.)
  • Visually rich: In order to make a quick determination about the best component, create a visual, interactive display of changes/updates across multiple versions.
  • Drive optimal component selection for new applications: Once your inventory is in place, you’ll be able to draw on that intelligence with new development efforts and select optimal components from the start. 

Determine your real threat exposure. Using generic, best practice policy templates, assess your key applications first to determine critical risk. This approach should be…

  • Policy driven: Assess your inventory based on policy guidance from the security, licensing and architecture teams. Again, their buy-in is important for the eventual rollout of a full-scale good component practice program.
  • Summarized: Make it easy on developers by creating an easy to understand visual summary that prioritizes risk across security, licensing and architecture dimensions. Developers should not be required to deconstruct the policy for each of these factors in order to determine what components to remediate.
  • Detailed: While it’s important to start at a summary level, the developer should be able to drill into the policy details – why does a component have risk? Be able to look at the specific security information (e.g., CVE), or specific licensing details (declared & observed), etc.
  • Prioritized: Support the ability to work down the list of component problems in priority order.
  • Flexibly Enforced: Start by auditing the applications first – report and alert problems to developers but don’t lock down access to components. Then, as you fine-tune the policies, implement appropriate enforcement actions throughout the development lifecycle.
  • Temporal Enforcement:  Increasing policy severity over time, gives developers more time to fix non-critical issues without modifications to the policy.  Migrating from one component to another can be controlled with temporal policy by starting the policy with an informational issues and automatic policy adjustment to a low or medium issue after a policy defined timer interval
  • Dependency Aware: Determine threat exposure for all components, not just locally defined dependencies. This means managing all components in the dependency tree (i.e., transitive dependencies).
  • Integrated throughout the lifecycle: As with Building an Inventory, determining your threat exposure should cut across steps. Enable component and vulnerability information in key places throughout the development process (Repo, IDE, Build).

Prevent vulnerabilities and quickly remediate flaws. Ultimately, enabling good component practice is about eliminating vulnerabilities by fixing flawed applications. The best practice is not just about fixing what is broken; it’s about preventing problems from the start. But regardless of how well you start your efforts, problems will crop up. New vulnerabilities for once clean components could be discovered, or you may be applying component management practices to existing applications in production or in development.

When faced with the task to shore up applications from risk, make sure your effort takes the following factors into account:

  • Priority driven: Drive remediation efforts based on a prioritized list of threats, and for remediation recommendations, guide developers with recommendations that inform component replacement based on security, licensing and quality factors.
  • Impact assessment: Provide developers the ability to assess the impact of change by identifying the delta between the components.
  • Migration assistance: Provide the ability to migrate to the new component directly in the developer environment (IDE) or provide migration guidance from the policy owner for hard to resolve issues.
  • Continuous monitoring: Ensure that you are continuously monitoring the applications for newly discovered threats.
  • Proactive (automated) alerting: Ensure that you are proactively notifying appropriate team members if new flaws are discovered.
  • Compliance driven: Remediation action should ensure that the applications are in compliance with defined policies.

For new development projects, the best way to prevent vulnerabilities is to “start clean” or, select optimal components at the start of the project. Beginning a project with components that are valid, trustworthy, free of vulnerabilities and meet a set criteria, will reduce downstream remediation efforts. Additionally, injecting the shared component intelligence into each stage of the lifecycle provides the basis for good decision-making by the entire team. 

Iterate & Tune, aka the “4th Step

As previously noted, it is recommended that you start your policy management using an audit process; you do not want to enforce until you are sure of what you have and the effects enforcement will have on Continuous Integration/Build Environment/Repository.

This 4th step requires an incremental approach to tuning policies so that:

  1. Policies map appropriately to organizational threat tolerance
  2. Policies do not generate noise that requires unnecessary effort on the development and security side
  3. Enforcement doesn’t become so strict as to slow the development effort

The “fourth step” is a critical, closer look at your previous efforts. We know it’s never easy to self-evaluate, but having the following in place will guide you in that criticism and help draw out actionable results to refine your good component efforts:

  • Contextual notifications: Use notifications and alerts to gauge the impact of enforcement action where and when issues arise. This means, provide these within the context of the developer tools instead of a punch list at the end of the cycle.
  • Tune policy criteria: Adjust the criteria so that your resources can appropriate manage the response. Do not be afraid to shift gears if you need too; now is the time.
  • Enable enforcement actions: After you have audited the policies, start enabling appropriate enforcement actions. For example, stop production deployment, or stop the build if the threat-level warrants.
  • Continually Assess: Schedule quick assessment points so that you continuously assess policy relevance.  This should be easy to do and should be a natural outcome of assessing enterprise risk using dashboards, reports and analysis.

Now that you have gained experience, you are ready for the rest of the journey. In this quick start chapter we didn’t address a formal methodology for deployment, things like formal discovery, pre-deployment planning, installation & configuration, training, infrastructure design, etc. Stay tuned for additional chapters to learn more about policy best practice (how to validate and tune the policies, how to adjust enforcement points, etc.) as well as the practice of continuous monitoring and ongoing risk assessment.

Mark Troester, AuthorMark Troester

As the IT/CIO Strategist, Mark leads the product marketing effort for Sonatype – specializing in IT & CIO strategy. Mark brings over 20 years of experience leading product marketing / management efforts for established vendors and startups that are focused on IT/CIO solutions.

He leverages his previous experience as a senior IT & development manager to focus on driving business value through technology. Mark led CIO and IT strategy and marketing efforts for SAS, formulating product and marketing direction in both technical and business domains. Mark holds a Bachelor’s degree in Computer Science from University of Missouri.