Criteria regarding security champions

[eddie-knight]

Regarding two suggestions from issue #155:

The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.)

At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.

Do we like the idea of placing requirements on lv3 maintainer training?

Pros:

• higher likeliness of catching security defects during reviews
• lower likeliness of designing security defects in the system
• improved responses to security incidents
• improved trust and reputation
• more qualified security champions may build better security culture on the project

Cons:

• barrier to graduation as projects struggle to ensure that a current maintainer has up-to-date training
• re-appropriation of resources toward training and credentials may frequently be met with pushback
• potentially unnecessary as projects at this level are likely to have a strong community to find defects

Questions:

• How do we manage those topical differences? For example, the maintainers on argo-cd will need to think of software, container, orchestration, and networking principles, while argo-helm maintainers may only need to think about infrastructure and networking security.
• Do we need a system to ensure that Lv3 maintainers have done some recent and topically applicable training?
• Do we want to add a field to the Security Insights champions to allow tracking of these credentials?

[funnelfiasco]

I'm not in favor of it as a general requirement. I think it's important, but it's the unfundiest of unfunded mandates, plus it puts us in the position of having to become accreditors of training courses as well. (Or we say something like "any LF-provided security course", which is a super bad look because it seems like we're just trying to force people to pay LF money if they want to be considered "secure").

I think this is one of those cases where it's a good idea, but if foundations want to require it, they should include it in additional requirements beyond Baseline.

[david-a-wheeler]

If we want people to produce secure software, they need to know how to do it. The details explains the specific criteria. It doesn't say "know everything", it lists what is required.

I recommend The Checklist Manifesto which shows that checklists are great for people who know what they're doing. If people don't know what they're doing, checklists tend to be ineffective. So, require knowledge as part of the checklist :-).

(Or we say something like "any LF-provided security course", which is a super bad look because it seems like we're just trying to force people to pay LF money if they want to be considered "secure").

The LFD121 is known to meet this criterion, and it's free.

We don't need to "accredit" a course. We don't accredit the rest of the criteria either.

barrier to graduation as projects struggle to ensure that a current maintainer has up-to-date training

All criteria are barriers, in the sense that they require something. That's the point of identifying criteria.

re-appropriation of resources toward training and credentials may frequently be met with pushback

If they already know it, there's no re-appropriation. There's no requirement for some specific credential, the requirement is knowledge.

If they don't know how to do this, then yes, there will be some time to do it. Great, we solved a problem! Also, we did a survey that suggests that developers generally like to learn things.

potentially unnecessary as projects at this level are likely to have a strong community to find defects

Developers want to find & fix defects, but if they don't know that something is a defect, they'll add the defect when writing software & won't fix it later. I agree that a security vulnerability is a kind of defect, but many developers don't have the knowledge to identify security defects. Many do; the goal is to make that common knowledge.

[david-a-wheeler]

The "topical" differences don't matter at the level of this criterion. E.g., "least privilege" is implemented differently in different systems, but that's always a relevant question to consider.

[funnelfiasco]

The LFD121 is known to meet this criterion, and it's free.

Free as in dollars, but not free as in time. 16-20 hours is a lot of time for people who aren't working on a project as their primary job. It's the main reason I haven't taken it yet, and open source has been my primarily job for the last seven years. 😅

One of the biggest complaints that I saw from developers about the GitHub Secure Open Source Fund was the time commitment involved. I worry we'll lose a lot of interest, even at lower levels of the Baseline, by requiring this. I fully agree that it's ideal, but I'm unconvinced it's practical. Of course, we have no way of knowing at this point how many of the projects that would be interested in achieving level 3 would already meet this requirement and of those that don't, how many would find it a blocker.

[david-a-wheeler]

Meeting this particular criterion would take less than an hour, as it only requires knowing specific design principles.

I think we should have higher expectations at level 3. Frankly, it's more important that people know what they're doing than that they meet some specific criteria. We can't possibly create a list of criteria to counter a fundamental lack of knowledge.

[david-a-wheeler]

In the best practices badge this is a low-level (passing) criterion. We have other 1,000 projects meeting it.

[david-a-wheeler]

BTW, the issue is "knowledge" and not really "champions". In the best practices badge we apply this criterion to single-person projects.