学一项技能_最后，一项安全开发技能的措施-优快云博客

学一项技能

Fostering sound and secure development by measuring programmer skill.

通过评估程序员的技能来促进健全，安全的开发。

Security vulnerabilities and data breaches are reported almost constantly, costing people time and effort dealing with potential identity theft or embarrassment and costing companies in profits and usage. Vulnerabilities in software are often caused by software developers’ errors, many of which could or should be preventable. Many researchers and companies provide tools, guidance, and education designed to help developers avoid these errors. But it’s hard to know which ones are most effective. What approach actually helps developers produce more secure code?

小号 ecurity漏洞和数据泄露的报道几乎不断，人们花费时间和精力处理潜在的身份盗窃或尴尬和成本计算公司利润和使用。软件中的漏洞通常是由软件开发人员的错误引起的，其中许多错误是可以避免或应该避免的。许多研究人员和公司提供了旨在帮助开发人员避免这些错误的工具，指南和培训。但是很难知道哪个是最有效的。哪种方法实际上可以帮助开发人员生成更安全的代码？

One common method researchers employ is to have developers take a secure development test before and after being given the intervention. Developers are asked to look through some code and identify a vulnerability or write a secure program. Unfortunately, only simple programs can be used without taking up a significant amount of the developer’s time. Even so, assessments can take hours to complete.

研究人员采用的一种常见方法是，让开发人员在受到干预之前和之后进行安全的开发测试。要求开发人员浏览一些代码并识别漏洞或编写安全程序。不幸的是，只有简单的程序可以使用，而不会占用开发人员的大量时间。即使这样，评估也可能需要数小时才能完成。

Alternatively, researchers have compared the number of vulnerabilities developers have introduced while working on real-world code. This approach is even more problematic. First, it can be a noisy indicator, as there are likely environmental factors, e.g., employer pressures, affecting vulnerability introduction. Also, it can be costly to collect this data: you either have to invest the time of experts to perform a security audit or wait until a malicious actor finds and exploits the vulnerability!

另外，研究人员比较了开发人员在处理实际代码时引入的漏洞数量。这种方法更成问题。首先，它可能是一个嘈杂的指标，因为可能存在环境因素，例如雇主的压力会影响引入漏洞。而且，收集这些数据可能会很昂贵：您要么必须花费专家的时间来执行安全审核，要么等到恶意参与者发现并利用该漏洞！

In our recent research, we sought to remedy this situation by developing a scale that can be used to assess how much someone knows about secure development, by asking them. Scales, or sets of predefined questions, are commonly employed by human behavior researchers to “measure elusive phenomena that cannot be observed directly” due to cost or complexity. (One of the most well-known examples is the Myers-Briggs personality scale.) Asking about something like secure development is more convenient than trying to measure skills directly, and somewhat surprisingly, it works fairly well: self-efficacy, or the belief in one’s ability to successfully perform a task, is often associated with actual skill. We call our scale the Secure Software Development Self-Efficacy Scale (SSD-SES).

在我们最近的研究中，我们试图通过开发一个量表来纠正这种情况，该量表可以通过询问来评估某人对安全开发的了解程度。由于成本或复杂性，人类行为研究人员通常使用量表或一组预定义的问题来“测量无法直接观察到的难以捉摸的现象” 。 (最著名的例子之一就是Myers-Briggs人格量表。)询问诸如安全发展之类的事情比尝试直接测量技能要方便得多，而且令人惊讶的是，它相当有效： 自我效能感或信念成功完成一项任务的能力通常与实际技能相关。我们称该量表为安全软件开发自我效能量表(SSD-SES)。

The key to this research, then, is figuring out the right questions to ask. We wanted to identify a representative set of secure development tasks and ask developers to tell us how well they believed they could perform each. To do this, we needed to determine the full set of tasks required for secure development. Then, because we don’t expect people to spend hours answering questions, we needed to pare down that list, focusing on questions most likely to find differences between developers. It’s not helpful to have participants answer questions that are, for all intents and purposes, redundant or that all participants answer the same way.

因此，这项研究的关键是找出正确的问题 。我们想确定一组具有代表性的安全开发任务，并请开发人员告诉我们他们认为自己可以很好地执行每个任务。为此，我们需要确定安全开发所需的全部任务。然后，因为我们不希望人们花很多时间来回答问题，所以我们需要缩减该列表，将重点放在最有可能发现开发人员之间差异的问题上。让参与者回答的问题对于所有意图和目的都是多余的，或者所有参与者都回答相同的方式是没有帮助的。

确定安全的开发任务 (Identifying secure development tasks)

To identify all possible secure development tasks, we started with a review of five popular secure development guidelines:

为了确定所有可能的安全开发任务，我们首先回顾了五种流行的安全开发准则：

NIST’s National Initiative for Cybersecurity Education framework (NICE)
NIST的国家网络安全教育倡议框架 (NICE)
The Building Security In Maturity Model (BSIMM)
成熟度模型中的建筑物安全性 (BSIMM)
OWASP’s Software Assurance Maturity Model (OSAMM)
OWASP的软件保障成熟度模型 (OSAMM)
Microsoft’s Security Development Lifecycle (SDL)
微软的安全开发生命周期 (SDL)
SAFECode’s Fundamental Practices for Secure Software Development framework
SAFECode 安全软件开发框架的基本实践

After reviewing each of these guidelines for unique tasks, we asked 22 secure development experts to review our task list. The experts rated each task and suggested tasks we might be missing.

在审查了每个指南中的独特任务之后，我们请22位安全开发专家来审查我们的任务列表。专家对每项任务进行了评分，并建议了我们可能缺少的任务。

After this exploratory review, we were left with 58 unique tasks within 8 categories: Determining security requirements, identifying attack vectors, identifying vulnerabilities, designing mitigations, designing for resiliency, testing, communicating security assumptions to colleagues, and communicating security assumptions with leadership and users.

在此探索性审查之后，我们剩下8个类别中的58个独特任务：确定安全要求，确定攻击媒介，确定漏洞，设计缓解措施，设计弹性，进行测试，向同事传达安全假设以及与领导和用户传达安全假设。

缩减任务列表 (Paring down the task list)

Next, we pared down our list by surveying 157 professional software developers. The goal of this survey was to weed out tasks that most developers responded to similarly and tasks developers didn’t think were relevant. After finishing this survey, we were left with 18 tasks.

接下来，我们通过对157位专业软件开发人员进行了调查来缩减列表。这项调查的目的是淘汰大多数开发人员以类似方式响应的任务，以及开发人员认为不相关的任务。完成调查后，我们剩下18项任务。

At this point, we also looked for groups of tasks, known as factors, where developers’ answers are related: your answer on one task in this group gives a pretty good idea of how you’ll answer other questions in the group. In fact, we found two factors of secure development self-efficacy: vulnerability discovery and mitigation, and security communication. This tells us that developers’ self-efficacy can improve in either of these dimensions independently, and we can target education and support tools depending on which factor(s) the developer needs more help with.

在这一点上，我们还寻找了与开发人员的答案相关的任务组，即factors ：您在该组中一项任务上的答案很好地说明了您将如何回答该组中的其他问题。实际上，我们发现了安全开发自我效能的两个因素：漏洞发现和缓解以及安全通信。这告诉我们，开发人员的自我效能可以在上述两个方面中的任意一个方面得到改善，并且我们可以根据开发人员需要更多帮助的因素来针对教育和支持工具。

确认我们的结果 (Confirming our results)

We tested the remaining 18 tasks with 146 developers. This second survey was intended to see whether we got similar responses from another set of developers, meaning that our scale produces consistent results. Primarily, we were looking for whether the grouping of responses into two factors matched our prior survey. For the most part, this was true. However, we removed 3 tasks that diverged from their previous group, resulting in our final 15-item scale.

我们与146个开发人员一起测试了其余18个任务。第二次调查旨在查看我们是否从另一组开发人员那里得到了类似的答复，这意味着我们的规模能产生一致的结果。首先，我们正在寻找将回答分为两个因素的分组是否与我们之前的调查相符。在大多数情况下，这是事实。但是，我们删除了3个与前一组不同的任务，最终形成了15个项目的规模。

We also wanted to make sure SSD-SES scores matched? with other indicators you might expect to relate to knowledge or skill in secure development. To do this, we also asked participants whether they had discovered a vulnerability previously or had regular contact and discussions with a security expert. Indeed, we found that this type of exposure to secure development experiences correlated with higher SSD-SES scores.

我们还想确保SSD-SES分数匹配？以及您可能期望与安全开发中的知识或技能相关的其他指标。为此，我们还询问了参与者以前是否发现了漏洞，或者与安全专家进行了定期联系和讨论。确实，我们发现，这种类型的安全开发经验与更高的SSD-SES分数相关。

如何使用SSD-SES (How to use SSD-SES)

Our final 15-item scale — formatted as survey questions used to administer it — is available here. The survey includes instructions to give developers who will answer the questions, as well as the questions themselves. To generate a total SSD-SES score, you simply sum the responses for each question (1 point for “I am not confident at all”, 5 points for “I am absolutely confident”).

我们的最终15项量表(格式为用于管理该表的调查问题) 在此处提供。该调查包括向要回答这些问题的开发人员以及问题本身的说明。要生成SSD-SES的总分，您只需将每个问题的答案相加即可(“我一点都不自信”为1分，“我绝对自信”为5分)。

If you’d like to measure the impact of your developer training program on secure development self-efficacy, you can have participants take the survey before and after and compare scores. You could also use the survey to probe current secure-development confidence among your team members and use the results to determine who may need additional support.

如果您想评估开发人员培训计划对安全开发自我效能的影响，则可以让参与者在进行调查之前和之后进行调查，并比较分数。您还可以使用调查来调查团队成员中当前的安全开发信心，并使用结果确定谁可能需要其他支持。

If you chose to use SSD-SES for any reason, we’d love to hear your feedback. Please feel free to email our research team at sec-pros@cs.umd.edu to tell us about your experience.

如果您出于任何原因选择使用SSD-SES，我们很乐意听到您的反馈。请随时通过sec-pros@cs.umd.edu向我们的研究团队发送电子邮件，以向我们介绍您的经验。

Read the full paper for additional details:

阅读全文以获得更多详细信息：

Daniel Votipka, Desiree Abrokwa, and Michelle L. Mazurek. Building and Validating a Scale for Secure Software Development Self-Efficacy. In Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI), 2020.
Daniel Votipka，Desiree Abrokwa和Michelle L. Mazurek。建立和验证安全软件开发自我效能的量表。在2020年ACM计算系统人为因素会议 (CHI)的会议记录中 。