Setting Your Risk Tolerance
& Prioritizing Risk

Understanding Risk Tolerance

It’s important to acknowledge that your applications will never be totally free of component risk. In fact, if you want an application free of component risk, you’ll need make an application without any components, and committing to that development budget probably isn’t feasible for your organization.

Instead, you’ll need to decide on a level of risk that you’re willing to accept –meaning, the risks that you won’t try to remove, mitigate, or remediate. Some risks are small enough that they can be safely ignored. Other risks are more serious, but don’t make sense to put any development budget towards. And some risks are severe but simply can’t be addressed.

After that, you’ll need to prioritize addressing the remaining risk. Some issues will need fixed immediately, and others can wait until your next sprint cycle, your next big release, or even your next round of funding.

Setting Tolerance on a Per-App Basis

For a given application, there are a number of factors to consider when estimating the acceptable risk level, such as the following:  

  • What is the violation’s level of threat to the organization?
  • Can the component be upgraded to a non-violating version?
  • Will upgrading the component require rework to fix breaking changes?
  • Is the violation exploitable in the application? Can the exploit be mitigated?
  • Could another open source component be used instead?

Budgeting for Tech Debt

Compliance with any free and open source software (FOSS) governance policy will slow innovation as a factor of technical debt. This equates to real development hours in dependency upgrading, CI testing, issue remediation, and, unfortunately, rework. A project will commonly allocate between 10-30% of an application’s budget to manage technical debt. Determining an application’s acceptable level of risk helps to prioritize remediation to fit these constraints.

To handle tech debt effectively, group applications in tiers depending on how critical they are to business continuity and impact, then assign tech debt budget accordingly. The following questions can help determine which tier of risk the application belongs to:

  • Does the application provide critical competitive advantage for the organization?
  • What is the cost of the application leaking user data?
  • Is the application internal- or external-facing?
  • Is the application in active development or legacy code?
  • Are there any external compliance requirements for the application?
  • Will an issue introduce risk into other applications?

Don’t Solve the Issue of Aging by Automatically Updating

Some projects avoid aging issues by automatically upgrading their dependencies when the last versions are available. This is often accomplished by including a version range in the manifest files either without an upper bound or one set to the next major version. This practice introduces another set of issues that is rapidly becoming riskier than aging. In general, we always recommend either pegging dependency versions and/or using project lock files to use versions that have been first vetted. Risks with open versioning include:

  • Trusting communities are widely exploited from contributors with malicious intent.
  • Dependency confusion attacks that target unreserved namespaces are now very common.
  • New releases may inadvertently introduce breaking changes.
  • Many available SCA tools perform namespace-matching without verifying the binaries used.
0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments