Security Requirements: Where OSS Projects Should Start

For developers running their own open source projects, defining security requirements is often the first thing skipped in favor of jumping straight into code. But taking time to establish a baseline standard before writing software pays off later: it reduces the chance of missing critical steps, implementing them out of order, or discovering costly problems after the fact. And for solo developers or small contributor teams, you don't need to build a custom security framework from scratch—the OWASP Application Security Verification Standard (ASVS) already provides a community-driven catalog of requirements and verification criteria you can adopt.

Standards tend to get a reputation for being dry and tedious, but they exist to make robust, secure code reproducible rather than accidental. The ASVS in particular was designed to remove ambiguity about what a modern, secure application looks like, giving you a concrete target to build against.

Filtering the ASVS to What Your Project Actually Needs

The ASVS organizes security requirements into 14 domains based on higher-order security functions. On its face, that's over 200 individual requirements—daunting for a small-to-medium project. But most projects won't need to consider all of them.

The trick is to use the domain structure as a filter. Each domain contains requirements written as verifiable statements, for example from V5 (Validation, Sanitization, and Encoding): Verify that URL redirects and forwards only allow known destinations, or show a warning when redirecting to potentially untrusted content. By first eliminating domains that don't apply to your application's functionality, you can build a focused Secure Coding Checklist tailored to your project.

Requirements are also tiered into three assurance levels, letting you scale effort to risk:

  • Level 1: Suitable for most projects that don't handle sensitive data—a reasonable starting point.
  • Level 2: For applications that store or process sensitive data requiring protection.
  • Level 3: The highest tier, intended for applications involving high-value transactions, sensitive medical data, or critical infrastructure like power or waste treatment plants. Most applications won't need this.

Combining domain relevance with an appropriate risk level gives you a direct way to filter hundreds of requirements down to a manageable, project-specific set.

A Worked Example: URL Parsing Library in Node

To see how this filtering works in practice, consider a small Node library for URL parsing. Several ASVS domains simply don't apply to a library with no authentication, session management, UI, or stored data—V2, V3, V4, V6, V8, V9, V11, V12, V13, and V14 can all be struck out immediately. That drops the requirement count from over 200 to 89. Choosing Level 1 as the starting risk tier cuts that further to 30 requirements, which is a realistic scope for a small project.

What kinds of requirements remain?

V1: Architecture, Design, and Threat Modeling

This domain covers core security attributes: availability, confidentiality, processing integrity, non-repudiation, and privacy. Applying it starts with assuming your URL parsing library will be handed user-controlled—and therefore untrusted—input. What happens if it fails to correctly identify URL parts like the host? What could an attacker exploit in that failure? This thinking-through of possible misuses is threat modeling, which boils down to four questions:

  1. What are you working on?
  2. What can go wrong—what's the worst that could happen?
  3. What are you going to do about it?
  4. Did you do a good enough job?

V5: Validation, Sanitization, and Encoding

Parsing URLs requires understanding their specification and identifying components precisely, including which metacharacters could break out of a given part. Say your library offers a function that constructs a URL from scheme, user, password, host, port, path, and query parameters. An application using it might hardcode the hostname (goodhost) while letting users supply their own username and password. If a user provides a username like badhost#, does your library properly encode the #? Per Appendix A of RFC 3986, the authority component permits only:

  • a-z, A-Z
  • 0-9
  • - . _ ~ ! $ & ‘ ( ) * + , ; = :
  • any percent-encoded character

Without correct encoding for the authority component's context, the # could slip through and let a user effectively rewrite the final URL (e.g., https://badhost#@goodhost), changing its meaning entirely.

V7: Error Handling and Logging

When parsing fails, errors should not be silently swallowed—a parse error can alter how a URL is interpreted, so it needs to surface.

V10: Malicious Code Verification

Even a small, personal library can gain adoption quickly, turning its repository into a potential vector for supply chain attacks via malicious contributions. Mitigations start with basic repository hygiene: branch protection, requiring verified commits, and securing CI/CD workflows. External contributions should be reviewed for vulnerabilities or code smells—ideally with SAST tooling integrated into the review workflow—and new contributors' commits should get at least two independent reviews.

From Requirements to Verification

Defining a security baseline from the ASVS needn't be an overwhelming exercise. Domains and risk levels let you reduce the standard to a curated set that makes sense for your project's size and purpose. Once those requirements are in place, the next step is testing that they're actually met—static analysis, dynamic analysis, or both. And after requirements come the enabling technologies: security libraries, frameworks, and secure defaults. But the foundation is deciding, up front, what "secure" means for your code.