schema-details.json

{
  "activities": {
    "SM.1.1": {
      "description": "The process for addressing software security is broadcast to all stakeholders so that everyone knows the plan. Goals, roles, responsibilities, and activities are explicitly defined. Most organizations pick and choose from a published methodology, such as the Microsoft SDL or the Cigital Touchpoints, and then tailor the methodology to their needs. An SSDL process must be adapted to the specifics of the development process it governs (e.g., waterfall, agile, etc) and evolves both with the organization and the security landscape. A process must be published to count. In many cases, the methodology is published only internally and is controlled by the SSG. The SSDL does not need to be publicly promoted outside of the firm to have the desired impact.",
      "resources"  : ["https://www.bsimm.com/framework/governance/software-security-metrics-strategy/", "https://intranet/link.to.details"],
      "objective"  : "make the plan explicit ",
      "proof"      : "Details should be published on wiki (see resource link)" },
    "SM.1.2": {
      "description": "In order to build support for software security throughout the organization, someone in the SSG plays an evangelism role. This internal marketing function helps keep executives and all other stakeholders current on the magnitude of the software security problem and the elements of its solution. Evangelists might give talks for internal groups including executives, extend invitations to outside speakers, author white papers for internal consumption, or create a collection of papers, books, and other resources on an internal website and promote its use. Ad hoc conversations between the SSG and executives, or an SSG where “everyone is an evangelist,” do not achieve the desired results. A canonical example of such an evangelist was Michael Howard’s role at Microsoft just after the Gates memo.",
      "resources"  : [],
      "objective"  : "build support throughout organization ",
      "proof"      : ""
    },
    "SM.1.3": {
      "description": "Executives are periodically shown the consequences of inadequate software security and the negative business impact that poor security can have. They’re also shown what other organizations are doing to attain software security. By understanding both the problem and its proper resolution, executives come to support the software security initiative as a risk management necessity. In its most dangerous form, such education arrives courtesy of malicious hackers or public data exposure incidents. Preferably, the SSG demonstrates a worst-case scenario in a controlled environment with the permission of all involved (e.g., actually showing working exploits and their business impact). In some cases, presentation to the Board can help garner resources for an ongoing software security initiative. Bringing in an outside guru is often helpful when seeking to bolster executive attention.",
      "resources"  : [],
      "objective"  : "secure executive buy-in ",
      "proof"      : ""
    },
    "SM.1.4": {
      "description": "The software security process includes release gates/checkpoints/milestones at one or more points in the SDLC or, more likely, the SDLCs. The first two steps toward establishing security-specific release gates are: 1) to identify gate locations that are compatible with existing development practices and 2) to begin gathering the input necessary for making a go/no-go decision. Importantly at this stage, the gates are not enforced. For example, the SSG can collect security testing results for each project prior to release, but stop short of passing judgment on what constitutes sufficient testing or acceptable test results. The idea of identifying gates first and only enforcing them later is extremely helpful in moving development toward software security without major pain. Socialize the gates, and only turn them on once most projects already know how to succeed. This gradual approach serves to motivate good behavior without requiring it.",
      "resources"  : [],
      "objective"  : "establish SSDL gates (but do not enforce) ",
      "proof"      : ""
    },
    "SM.2.1": {
      "description": "The SSG publishes data internally on the state of software security within the organization to facilitate improvement. The information might come as a dashboard with metrics for executives and software development management. Sometimes, publication is not shared with everyone in a firm, but rather with the relevant executives only. In this case, publishing information up to executives who then drive change in the organization is necessary. In other cases, open book management and publishing data to all stakeholders helps everyone know what’s going on, with the philosophy that sunlight is the best disinfectant. If the organization’s culture promotes internal competition between groups, this information adds a security dimension to the game.",
      "resources"  : [],
      "objective"  : "foster transparency (or competition) ",
      "proof"      : ""
    },
    "SM.2.2": {
      "description": "SDLC security gates are now enforced: in order to pass a gate, a project must either meet an established measure or obtain a waiver. Even recalcitrant project teams must now play along. The SSG tracks exceptions. A gate could require a project to undergo code review and remediate any critical findings before release. In some cases, gates are directly associated with controls required by regulations, contractual agreements, and other business obligations, and exceptions are tracked as required by statutory or regulatory drivers. In other cases, gate measures yield key performance indicators that are used to govern the process. A revolving door or a rubber stamp exception process does not count. If some projects are automatically passed, that defeats the purpose of enforcing gates.",
      "resources"  : [],
      "objective"  : "change behavior ",
      "proof"      : ""
    },
    "SM.2.3": {
      "description": "The satellite begins as a collection of people scattered across the organization who show an above-average level of security interest or skill. Identifying this group is a step towards creating a social network that speeds the adoption of security into software development. One way to begin is to track the people who stand out during introductory training courses (see T2.7 Identify satellite through training). Another way is to ask for volunteers. In a more top-down approach, initial satellite membership is assigned to ensure complete coverage of all development/product groups. Ongoing membership should be based on actual performance. A strong satellite is a good sign of a mature software security initiative.",
      "resources"  : [],
      "objective"  : "create broad base of support ",
      "proof"      : ""
    },
    "SM.2.6": {
      "description": "The organization has an initiative-wide process for accepting security risk and documenting accountability. A risk acceptor signs off on the state of all software prior to release. For example, the sign-off policy might require the head of the business unit to sign off on critical vulnerabilities that have not been mitigated or SSDL steps that have been skipped. Informal risk acceptance alone does not count as security sign off, as the act of accepting risk is more effective when it is formalized (e.g., with a signature, form submission, or something similar) and captured for future reference. Similarly, simply stating that certain projects never need a sign-off does not achieve the desired results.",
      "resources"  : [],
      "objective"  : "make clear who's taking the risk ",
      "proof"      : ""
    },
    "SM.3.1": {
      "description": "The SSG uses a centralized tracking application to chart the progress of every piece of software in its purview. The application records the security activities scheduled, in progress and completed. It incorporates results from activities such as architecture analysis, code review, and security testing. The SSG uses the tracking application to generate portfolio reports for many of the metrics it uses. A combined inventory and risk posture view is fundamental. In many cases, these data are published at least among executives. Depending on the culture, this can cause interesting effects through internal competition. As an initiative matures and activities become more distributed, the SSG uses the centralized reporting system to keep track of all of the moving parts.",
      "resources"  : [],
      "objective"  : "know where all apps in your inventory stand ",
      "proof"      : ""
    },
    "SM.3.2": {
      "description": "The SSG helps the firm market the software security initiative outside to build external support. Software security grows beyond being a risk reduction exercise and becomes a competitive advantage or market differentiator. The SSG might write papers or books about its SSDL. It might have a public blog. It might participate in external conferences or trade shows. In some cases, a complete SSDL methodology can be published and promoted externally. Sharing details externally and inviting critique can bring new perspectives into the firm.",
      "resources"  : [],
      "objective"  : "create external support ",
      "proof"      : ""
    },
    "SM.3.3": {
      "description": " Identify metrics and use them to drive budgets.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "CP.1.1": {
      "description": "If the business or its customers are subject to regulatory or compliance drivers such as FFIEC, GLBA, OCC, PCI DSS, SOX, HIPAA, or others, the SSG acts as a focal point for understanding the constraints such drivers impose on software. In some cases, the SSG creates a unified approach that removes redundancy from overlapping compliance requirements. A formal approach will map applicable portions of regulations to control statements explaining how the organization complies. As an alternative, existing business processes run by legal or other risk and compliance groups outside the SSG could also serve as the regulatory focal point. The goal of this activity is to create one set of software security guidance so that compliance work is completed as efficiently as possible (mostly by removing duplicates). Some firms move on to guide exposure by becoming directly involved in standards groups in order to influence the regulatory environment.",
      "resources"  : [],
      "objective"  : "understand compliance drivers (FFIEC, GLBA, OCC, PCI, SOX, SAS 70, HIPAA) ",
      "proof"      : ""
    },
    "CP.1.2": {
      "description": "The way software handles personally identifiable information (PII) could be explicitly regulated, but even if it isn’t, privacy is a hot topic. The SSG plays a key role in identifying and describing PII obligations stemming from regulation and customer expectations. It uses this information to promote best practices related to privacy. For example, if the organization processes credit card transactions, the SSG will identify the constraints that the PCI DSS places on the handling of cardholder data and inform all stakeholders. Note that outsourcing to hosted environments (e.g., the cloud) does not relax a majority of PII obligations. Also note, firms that create software products that process PII (but who don’t necessarily handle PII directly) can get credit by providing privacy controls and guidance for their customers.",
      "resources"  : [],
      "objective"  : "promote privacy ",
      "proof"      : ""
    },
    "CP.1.3": {
      "description": "The SSG guides the rest of the organization by creating or contributing to software security policy that satisfies regulatory and customer-driven security requirements. The policy provides a unified approach for satisfying the (potentially lengthy) list of security drivers at the governance level. As a result, project teams can avoid keeping up with the details involved in complying with all applicable regulations. Likewise, project teams don’t need to re-learn customer security requirements on their own. The SSG policy documents are sometimes focused around major compliance topics such as the handling of PII or the use of cryptography. In some cases, policy documents relate directly to the SSDL and its use in the firm. Architecture standards and coding guidelines are not examples of software security policy. On the other hand, policy that prescribes and mandates the use of coding guidelines and architecture standards for certain categories of applications does count. Policy is what is permitted and denied at the initiative level. If it’s not mandatory, it’s not policy.",
      "resources"  : [],
      "objective"  : "meet regulatory needs or customer demand with a unified approach ",
      "proof"      : ""
    },
    "CP.2.1": {
      "description": "The organization identifies the kinds of PII stored by each of its systems and their data repositories. A PII inventory can be approached in two ways: starting with each individual application by noting its PII use or starting with particular types of PII and the applications that touch them. In either case, an inventory of data repositories is required. When combined with the organization’s PII obligations, this inventory guides privacy planning. For example, the SSG can now create a list of databases that would require customer notification if breached.",
      "resources"  : [],
      "objective"  : "promote privacy ",
      "proof"      : ""
    },
    "CP.2.2": {
      "description": "The organization has a formal compliance risk acceptance and accountability process addressing all software development projects. The SSG might act as an advisor when the risk acceptor signs off on the state of the software prior to release. For example, the sign-off policy might require the head of the business unit to sign off on compliance issues that have not been mitigated or SSDL steps related to compliance that have been skipped. Signoff should be explicit and captured for future reference. Any exceptions should be tracked.",
      "resources"  : [],
      "objective"  : "ensure accountability for software risk ",
      "proof"      : ""
    },
    "CP.2.3": {
      "description": "The organization can demonstrate compliance with applicable regulations because its SSDL is aligned with the control statements developed by the SSG (see CP1.1 Unify regulatory pressures). The SSG tracks the controls, shepherds problem areas, and makes sure auditors and regulators are satisfied. If the organization’s SDLC is predictable and reliable, the SSG might be able to largely sit back and keep score. If the SDLC is uneven or less reliable, the SSG could be forced to take a more active role as referee. A firm doing this properly can explicitly associate satisfying its compliance concerns to following its SSDL.",
      "resources"  : [],
      "objective"  : "align practices with compliance ",
      "proof"      : ""
    },
    "CP.2.4": {
      "description": "Vendor contracts include a service-level agreement (SLA) ensuring that the vendor will not jeopardize the organization’s compliance story and software security initiative. Each new or renewed contract contains a set of provisions requiring the vendor to address software security and deliver a product or service compatible with the organization’s security policy (see SR2.5 Create SLA boilerplate). In some cases, open source licensing concerns initiate the vendor control process. That can open the door for further software security language in the SLA. Traditional IT security requirements and a simple agreement to allow penetration testing are not sufficient.",
      "resources"  : [],
      "objective"  : "ensure vendors don't screw up compliance ",
      "proof"      : ""
    },
    "CP.2.5": {
      "description": "The SSG gains executive buy-in around compliance and privacy activities. Executives are provided plain-language explanations of the organization’s compliance and privacy obligations and the potential consequences for failing to meet those obligations. For some organizations, explaining the direct cost and likely fallout from a data breach could be an effective way to broach the subject. For other organizations, having an outside expert address the Board works because some executives value outside perspective more than internal perspective. One sure sign of proper executive awareness is adequate allocation of resources to get the job done. Be aware that the light and heat typically following a breach will not last.",
      "resources"  : [],
      "objective"  : "gain executive buy-in ",
      "proof"      : ""
    },
    "CP.3.1": {
      "description": "The SSG has the information regulators want. A combination of written policy, controls documentation, and artifacts gathered through the SSDL gives the SSG the ability to demonstrate the organization’s compliance story without a fire drill for every audit. In some cases, regulators, auditors, and senior management are satisfied with the same kinds of reports, which may be generated directly from various tools.",
      "resources"  : [],
      "objective"  : "demonstrate compliance story ",
      "proof"      : ""
    },
    "CP.3.2": {
      "description": "Vendors are required to adhere to the same policies used internally. Vendors must submit evidence that their software security practices pass muster. Evidence could include results from code reviews or penetration tests. Vendors may also attest to the fact that they are carrying out certain SSDL processes. In some cases, a BSIMM score or a vBSIMM score has been used to help ensure that vendors are complying with the firm’s policies.",
      "resources"  : [],
      "objective"  : "manage third-party vendors ",
      "proof"      : ""
    },
    "CP.3.3": {
      "description": "Information from the SSDL is routinely fed back into the policy creation process. Policies are improved to find defects earlier or prevent them from occurring in the first place. Blind spots are eliminated based on trends in SSDL failures. For example, inadequate architecture analysis, recurring vulnerabilities, ignored security gates, or choosing the wrong firm to carry out a penetration test may expose policy weakness. Over time, policies should become more practical and easier to carry out (see SM1.1 Publish process (roles, responsibilities, plan), evolve as necessary). Ultimately, policies align themselves with the SSDL data and enhance and improve a firm’s effectiveness.",
      "resources"  : [],
      "objective"  : "keep policy aligned with reality ",
      "proof"      : ""
    },


    "T.1.1": {
      "description": "The SSG provides awareness training in order to promote a culture of software security throughout the organization. Training might be delivered by SSG members, by an outside firm, by the internal training organization, or through eLearning. Course content isn’t necessarily tailored for a specific audience. For example, all programmers, quality assurance engineers, and project managers could attend the same ‘Introduction to Software Security’ course. This common activity can be enhanced with a tailored approach to an introductory course that addresses a firm’s culture explicitly. Generic introductory courses covering basic IT security and high-level software security concepts do not generate satisfactory results. Likewise, providing awareness training only to developers and not to other roles is also insufficient.",
      "resources"  : [],
      "objective"  : "promote culture of security throughout the organization ",
      "proof"      : ""
    },
    "T.1.5": {
      "description": "Software security training goes beyond building awareness and enables trainees to incorporate security practices into their work. The training is tailored to the role of trainees; trainees get information about the tools, technology stacks, or kinds of bugs that are most relevant to them. An organization might offer four tracks for engineers: one for architects, one for Java developers, one for Ruby developers, and a fourth for testers. Tool-specific training is also commonly observed in a curriculum. Don’t forget that training will be useful for many different roles in an organization, including QA, product management, executives, and others.",
      "resources"  : [],
      "objective"  : "build capabilities beyond awareness ",
      "proof"      : ""
    },
    "T.1.6": {
      "description": "In order to make a strong and lasting change in behavior, training includes material specific to the company’s history. When participants can see themselves in the problem, they are more likely to understand how the material is relevant to their work and to know when and how to apply what they have learned. One way to do this is to use noteworthy attacks on the company as examples in the training curriculum. Be wary of training that covers platforms not used by developers (Windows developers don’t care about old Unix problems) or examples of problems only relevant to languages no longer in common use (Java developers don’t need to understand buffer overflows in C). Stories from company history can help steer training in the right direction only if the stories are still relevant and not overly censored.",
      "resources"  : [],
      "objective"  : "see yourself in the problem ",
      "proof"      : ""
    },
    "T.1.7": {
      "description": "The organization lowers the burden on trainees and reduces the cost of delivering training by offering on-demand training for individuals across roles. eLearning is the most obvious choice and can be kept up-to-date through a subscription model. Online courses must be engaging and relevant to achieve their intended purpose. For developers, it is also possible to provide training directly through IDEs right at the time it’s needed. Remember that in some cases, building a new skill (such as code review) could be better suited for instructor-led training. Of course, training that sits around on the shelf does nobody any good.",
      "resources"  : [],
      "objective"  : "reduce impact on training targets and delivery staff ",
      "proof"      : ""
    },
    "T.2.5": {
      "description": "The SSG strengthens the social network by holding special events for the satellite. The satellite learns about advanced topics or hears from guest speakers. Offering pizza and beer doesn’t hurt. A standing conference call with voluntary attendance does not address this activity, which is as much about building camaraderie as it is about sharing knowledge or organizational efficiency. There’s no substitute for face-to-face meetings, even if they happen only once or twice a year.",
      "resources"  : [],
      "objective"  : "educate/strengthen social network ",
      "proof"      : ""
    },
    "T.2.6": {
      "description": "The process for bringing new hires into the engineering organization requires a module about software security. The generic new hire process covers things like picking a good password and making sure people don’t tail you into the building, but this can be enhanced to cover topics such as secure coding, the SSDL, and internal security resources. The objective is to ensure that new hires enhance the security culture. Turnover in engineering organizations is generally high. Though a generic onboarding module is useful, it does not take the place of a timely and more complete introductory software security course.",
      "resources"  : [],
      "objective"  : "ensure new hires enhance culture ",
      "proof"      : ""
    },

    "T.3.1": {
      "description": "Knowledge is its own reward, but progression through the security curriculum brings other benefits too. Developers, testers, and others see a career advantage in learning about security. The reward system can be formal and lead to a certification or official mark in the HR system, or it can be less formal and use motivators such as praise letters for the satellite written at annual review time. Involving a corporate training department and/or HR can make security’s impact on career progression more obvious, but the SSG should continue to monitor security knowledge in the firm and not cede complete control or oversight.",
      "resources"  : [],
      "objective"  : "align security culture with career path ",
      "proof"      : ""
    },
    "T.3.2": {
      "description": "Spending time and effort helping suppliers get security right at the outset is easier than trying to figure out what they screwed up later on. In the best case, outsourced workers receive the same training given to employees. Training individual contractors is much more natural than training entire outsource firms and is a reasonable way to start. Of course, it’s important to train everyone who works on your software regardless of their employment status.",
      "resources"  : [],
      "objective"  : "spread security culture to providers ",
      "proof"      : ""
    },
    "T.3.3": {
      "description": "The organization highlights its security culture as a differentiator by hosting security events featuring external speakers and content. Good examples of this are Microsoft’s BlueHat and Intel’s Security Conference. Employees benefit from hearing outside perspectives. The organization as a whole benefits from putting its security cred on display (see SM3.2 Run an external marketing program). Events open to just certain small groups will not result in the desired change.",
      "resources"  : [],
      "objective"  : "market security culture as differentiator ",
      "proof"      : ""
    },
    "T.3.4": {
      "description": "Everyone involved in the SSDL is required to take an annual software security refresher course. The refresher keeps the staff up-to-date on security and ensures the organization doesn’t lose focus due to turnover. The SSG might use half a day to give an update on the security landscape and explain changes to policies and standards. A refresher can be rolled out as part of a firm-wide security day or in concert with an internal security conference.",
      "resources"  : [],
      "objective"  : "keep staff up-to-date and address turnover ",
      "proof"      : ""
    },
    "T.3.5": {
      "description": "The SSG offers help to any and all comers during an advertised lab period or regularly scheduled office hours. By acting as an informal resource for people who want to solve security problems, the SSG leverages teachable moments and emphasizes the carrot over the stick. Office hours might be held one afternoon per week in the office of a senior SSG member. Mobile office hours are also a possibility, with visits to particular product or application groups slated by request.",
      "resources"  : [],
      "objective"  : "act as informal resource to leverage teachable moments ",
      "proof"      : ""
    },
    "T.3.6": {
      "description": "Identify a satellite through training.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },


    "AM.1.2": {
      "description": "The organization agrees upon a data classification scheme and uses the scheme to inventory its software according to the kinds of data the software handles. This allows applications to be prioritized by their data classification. Many classification schemes are possible—one approach is to focus on PII. Depending upon the scheme and the software involved, it could be easiest to first classify data repositories, then derive classifications for applications according to the repositories they use. Other approaches to the problem are possible. For example, data could be classified according to protection of intellectual property, impact of disclosure, exposure to attack, relevance to SOX, or geographic boundaries.",
      "resources"  : [],
      "objective"  : "prioritize applications by data consumed/manipulated ",
      "proof"      : ""
    },
    "AM.1.3": {
      "description": "The SSG identifies potential attackers in order to understand their motivations and capabilities. The outcome of this exercise could be a set of attacker profiles including generic sketches for categories of attackers and more detailed descriptions for noteworthy individuals. In some cases, a third-party vendor might be contracted to provide this information. Specific and contextual attacker information is almost always more useful than generic information copied from someone else’s list.",
      "resources"  : [],
      "objective"  : "understand the \"who\" of attacks ",
      "proof"      : ""
    },

    "AM.1.5": {
      "description": "The SSG stays ahead of the curve by learning about new types of attacks and vulnerabilities. The information comes from attending conferences and workshops, monitoring attacker forums, and reading relevant publications, mailing lists, and blogs. Make Sun Tzu proud by knowing your enemy; engage with the security researchers who are likely to cause you trouble. In many cases, a subscription to a commercial service provides a reasonable way of gathering basic attack intelligence. Regardless of its origin, attack information must be made actionable and useful for software builders and testers.",
      "resources"  : [],
      "objective"  : "stay current on attack/vulnerability environment ",
      "proof"      : ""
    },

    "AM.2.1": {
      "description": "The SSG prepares for security testing and architecture analysis by building attack patterns and abuse cases tied to potential attackers. These resources don’t have to be built from scratch for every application in order to be useful. Instead, there could be standard sets for applications with similar profiles. The SSG will add to the pile based on attack stories. For example, a story about an attack against poorly managed entitlements could lead to an entitlements attack pattern that drives a new type of testing. If a firm tracks fraud and monetary costs associated with particular attacks, this information can be used to guide the process of building attack patterns and abuse cases.",
      "resources"  : [],
      "objective"  : "provide resources for security testing and AA ",
      "proof"      : ""
    },
    "AM.2.2": {
      "description": "The SSG creates technology-specific attack patterns to capture knowledge about attacks that target particular technologies. For example, if the organization’s web software relies on cutting-edge browser capabilities, the SSG could catalogue the quirks of all the popular browsers and how they might be exploited. Attack patterns directly related to the security frontier (e.g., mobile security and wearable computing) can be useful. Simply republishing general guidelines (e.g., “Ensure data are protected in transit”) and adding “for mobile applications” on the end does not constitute technology-specific attack patterns.",
      "resources"  : [],
      "objective"  : "understand technology-driven attacks ",
      "proof"      : ""
    },
    "AM.2.5": {
      "description": "Build and maintain a top N possible attacks list.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "AM.2.6": {
      "description": "Collect and publish attack stories.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "AM.2.7": {
      "description": "Build an internal forum to discuss attacks.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "AM.3.1": {
      "description": "The SSG has a science team that works to identify and defang new classes of attacks before real attackers even know they exist. This isn’t a penetration testing team finding new instances of known types of weaknesses—it’s a research group innovating new types of attacks. A science team may include well-known security researchers who publish their findings at conferences like Def Con.",
      "resources"  : [],
      "objective"  : "get ahead of the attack curve ",
      "proof"      : ""
    },
    "AM.3.2": {
      "description": "The SSG arms testers and auditors with automation to do what attackers are going to do. For example, a new attack method identified by the science team could require a new tool. The SSG packages the new tool and distributes it to testers. The idea here is to push attack capability past what typical commercial tools and offerings encompass and then package that information for others to use. Tailoring these new tools to a firm’s particular technology stacks and potential attackers is a really good idea.",
      "resources"  : [],
      "objective"  : "arm testers and auditors ",
      "proof"      : ""
    },


    "SFD.1.1": {
      "description": "Some problems are best solved only once. Rather than have each project team implement all of their own security features (e.g., authentication, role management, key management, audit/log, cryptography, protocols), the SSG provides proactive guidance by building and publishing security features for other groups to use. Project teams benefit from implementations that come pre-approved by the SSG and the SSG benefits by not having to repeatedly track down the kinds of subtle errors that often creep into security features. The SSG can identify an implementation they like and promote it as the accepted solution.",
      "resources"  : [],
      "objective"  : "create proactive security guidance around security features ",
      "proof"      : ""
    },
    "SFD.1.2": {
      "description": "Security is a regular part of the organization’s software architecture discussion. The architecture group takes responsibility for security the same way they take responsibility for performance, availability or scalability. One way to keep security from falling out of the discussion is to have an SSG member attend regular architecture meetings. In other cases, enterprise architecture can help the SSG create secure designs that integrate properly into corporate design standards. Proactive engagement by the SSG is key to success.",
      "resources"  : [],
      "objective"  : "inject security thinking into architecture group ",
      "proof"      : ""
    },
    "SFD.2.1": {
      "description": "The SSG takes a proactive role in software design by building or providing pointers to secure-by-design middleware frameworks or common libraries. In addition to teaching by example, this middleware aids architecture analysis and code review because the building blocks make it easier to spot errors. For example, the SSG could modify a popular web framework, such as Spring, to make it easy to meet input validation requirements. Eventually the SSG can tailor code review rules specifically for the components it offers (see CR3.1 Use automated tools with tailored rules). When adopting a middleware framework (or any other widely used software), careful vetting for security before publication is important. Encouraging adoption and use of insecure middleware does not help the software security situation. Generic open source software security architectures, including OWASP ESAPI, should not be considered secure by design. Bolting security on at the end by calling a library is not the way to approach secure design.",
      "resources"  : [],
      "objective"  : "create proactive security design based on technology stacks",
      "proof"      : ""
    },
    "SFD.2.2": {
      "description": "When the SSG is involved early in the new project process, it contributes to new architecture and solves difficult design problems. The negative impact security has on other constraints (time to market, price, etc.) is minimized. If a skilled security architect from the SSG is involved in the design of a new protocol, he or she could analyze the security implications of existing protocols and identify elements that should be duplicated or avoided. Designing for security up front is more efficient than analyzing an existing design for security and then refactoring when flaws are uncovered. Some design problems will require specific expertise outside of the SSG.",
      "resources"  : [],
      "objective"  : "address the need for new architecture ",
      "proof"      : ""
    },
    "SFD.3.1": {
      "description": "A review board or central committee formalizes the process for reaching consensus on design needs and security tradeoffs. Unlike the architecture committee, this group is specifically focused on providing security guidance. The group also periodically reviews already-published design standards (especially around cryptography) to ensure that design decisions do not become stale or out of date.",
      "resources"  : [],
      "objective"  : "formalize consensus on design ",
      "proof"      : ""
    },
    "SFD.3.2": {
      "description": "Implementers must take their security features and frameworks from an approved list. There are two benefits: developers do not spend time re-inventing existing capabilities and review teams do not have to contend with finding the same old defects in brand new projects. In particular, the more a project uses proven components, the easier architecture analysis and code review become (see AA1.1 Perform security feature review). Re-use is a major advantage of consistent software architecture.",
      "resources"  : [],
      "objective"  : "promote design efficiency ",
      "proof"      : ""
    },
    "SFD.3.3": {
      "description": "The SSG fosters centralized design reuse by collecting design patterns from across the organization and publishing them for everyone to use. A section of the SSG website could promote positive elements identified during architecture analysis so that good ideas are spread. This process should be formalized. An ad hoc, accidental noticing is not sufficient. In some cases, a central architecture or technology team facilitates and enhances this activity.",
      "resources"  : [],
      "objective"  : "practice reuse ",
      "proof"      : ""
    },

    "SR.1.1": {
      "description": "Software security requires much more than security features, but security features are part of the job as well. The SSG meets the organization’s demand for security guidance by creating standards that explain the accepted way to adhere to policy and carry out specific security-centric operations. A standard might describe how to perform authentication using J2EE or how to determine the authenticity of a software update (see SFD1.1 Build and publish security features for one case where the SSG provides a reference implementation of a security standard). Standards can be deployed in a variety of ways. In some cases, standards and guidelines can be automated in development environments (e.g., worked into an IDE). In other cases, guidelines can be explicitly linked to code examples to make them more actionable and relevant. Standards that are not widely adopted and enforced are not really standards.",
      "resources"  : [],
      "objective"  : "meet demand for security features ",
      "proof"      : ""
    },
    "SR.1.2": {
      "description": "The organization has a well-known central location for information about software security. Typically, this is an internal website maintained by the SSG. People refer to the site for the latest and greatest on security standards and requirements as well as other resources provided by the SSG. An interactive wiki is better than a static portal with guideline documents that rarely change. Organizations can supplement these materials with mailing lists and face-to-face meetings.",
      "resources"  : [],
      "objective"  : "ensure that everybody knows where to get latest and greatest ",
      "proof"      : ""
    },
    "SR.1.3": {
      "description": "Compliance constraints are translated into software requirements for individual projects. This is a linchpin in the organization’s compliance strategy—by representing compliance constraints explicitly with requirements, demonstrating compliance becomes a manageable task. For example, if the organization routinely builds software that processes credit card transactions, PCI DSS compliance could play a role in the SSDL during the requirements phase. In other cases, technology standards built for international interoperability reasons can include security guidance. Representing these standards as requirements helps with traceability and visibility in the case of audit.",
      "resources"  : [],
      "objective"  : "compliance strategy ",
      "proof"      : ""
    },
    "SR.2.2": {
      "description": "The organization creates a standards review board to formalize the process used to develop standards and ensure that all stakeholders have a chance to weigh in. The review board could operate by appointing a champion for any proposed standard. The onus is on the champion to demonstrate that the standard meets its goals and to get approval and buy-in from the review board. Enterprise architecture or enterprise risk groups sometimes take on the responsibility of creating and managing standards review boards.",
      "resources"  : [],
      "objective"  : "formalize standards process ",
      "proof"      : ""
    },
    "SR.2.3": {
      "description": "The organization standardizes on specific technology stacks. For the SSG, this means a reduced workload because the group does not have to explore new technology risks for every new project. Ideally, the organization will create a secure base configuration for each technology stack, further reducing the amount of work required to use the stack safely. A stack might include an operating system, a database, an application server, and a runtime environment for a managed language. The security frontier is a good place to find traction. Currently, mobile technology stacks and platforms as well as cloud-based technology stacks are two areas where specific attention to security pays off.",
      "resources"  : [],
      "objective"  : "reduce SSG workload ",
      "proof"      : ""
    },
    "SR.2.4": {
      "description": "The first step toward managing risk introduced by open source is to identify the open source components in use across the portfolio. It’s not uncommon to discover old versions of components with known vulnerabilities or multiple versions of the same component. Automated tools for finding open source, whether whole components or large chunks of borrowed code, are one way to approach this activity. A process that relies solely on developers asking for permission does not generate satisfactory results. At the next level of maturity, this activity is subsumed by a policy constraining the use of open source.",
      "resources"  : [],
      "objective"  : "manage open source risk ",
      "proof"      : ""
    },
    "SR.2.5": {
      "description": "The SSG works with the legal department to create a standard SLA boilerplate that is used in contracts with vendors and outsource providers to require software security efforts. The legal department understands that the boilerplate also helps prevent compliance and privacy problems. Under the agreement, vendors and outsource providers must meet company software security standards (see CP2.4 Paper all vendor contracts with software security SLAs). Boilerplate language may call out software security vendor control solutions such as vBSIMM measurements or BSIMM scores.",
      "resources"  : [],
      "objective"  : "gain buy-in from legal department and standardize approach ",
      "proof"      : ""
    },

    "SR.3.1": {
      "description": "The organization has control over its exposure to the vulnerabilities that come along with using open source components. Use of open source could be restricted to pre-defined projects. It could also be restricted to open source versions that have been through an SSG security screening process, had unacceptable vulnerabilities remediated, and made available only through internal repositories. Legal often spearheads additional open source controls due to the “viral” license problem associated with GPL code. Getting legal to understand security risks can help move an organization to practice decent open source hygiene. Of course, this control must be applied across the software portfolio.",
      "resources"  : [],
      "objective"  : "manage open source risk ",
      "proof"      : ""
    },
    "SR.3.2": {
      "description": "The SSG works with vendors to educate them and promote the organization’s security standards. A healthy relationship with a vendor cannot be guaranteed through contract language alone. The SSG engages with vendors, discusses the vendor’s security practices and explains in concrete terms (rather than legalese) what the organization expects of the vendor. Any time a vendor adopts the organization’s security standards, it’s a clear win. When a firm’s SSDL is available publically, communication regarding software security expectations is easier. Likewise, sharing internal practices and measures can make expectations very clear.",
      "resources"  : [],
      "objective"  : "educate third-party vendors ",
      "proof"      : ""
    },
    "SR.3.3": {
      "description": "Use secure coding standards.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "AA.1.1": {
      "description": "To get started in architecture analysis, center the process on a review of security features. Security-aware reviewers first identify the security features in an application (authentication, access control, use of cryptography, etc.) then study the design looking for problems that would cause these features to fail at their purpose or otherwise prove insufficient. For example, a system that was subject to escalation of privilege attacks because of broken access control or a system that stored unsalted password hashes would both be identified in this kind of review. At higher levels of maturity, the activity of reviewing features is eclipsed by a more thorough approach to architecture analysis. In some cases, use of the firm’s secure-by-design components can streamline this process.",
      "resources"  : [],
      "objective"  : "get started with AA ",
      "proof"      : ""
    },
    "AA.1.2": {
      "description": "The organization learns about the benefits of architecture analysis by seeing real results for a few high-risk, high-profile applications. The reviewers must have some experience performing detailed design review and breaking the architecture being considered. In all cases, design review produces a set of architecture flaws and a plan to mitigate them. If the SSG is not yet equipped to perform an in-depth architecture analysis, it uses consultants to do this work. Ad hoc review paradigms that rely heavily on expertise can be used here, though in the long run they do not scale. A review focused only on whether a software project has performed the right process steps will not generate expected results.",
      "resources"  : [],
      "objective"  : "demonstrate value of AA with real data ",
      "proof"      : ""
    },
    "AA.1.3": {
      "description": "The SSG takes a lead role in architecture analysis by performing design review to build the organization’s ability to uncover design flaws. Breaking an architecture is enough of an art that the SSG must be proficient at it before they can turn the job over to the architects, and proficiency requires practice. The SSG cannot be successful on its own either—it’s likely they’ll need help from architects or implementers to understand the design. With a clear design in hand, the SSG might carry out the detailed review with a minimum of interaction with the project team. At higher levels of maturity, the responsibility for leading review efforts shifts towards software architects. Approaches to architecture analysis (and threat modeling) evolve over time. Do not expect to set a process and use it forever.",
      "resources"  : [],
      "objective"  : "build internal capability on security architecture ",
      "proof"      : ""
    },
    "AA.1.4": {
      "description": "To facilitate security feature and design review processes, the SSG uses a risk questionnaire to collect basic information about each application so that it can determine a risk classification and prioritization scheme. Questions might include, “Which programming languages is the application written in?” “Who uses the application?” and “Does the application handle PII?” A qualified member of the application team completes the questionnaire. The questionnaire is short enough to be completed in a matter of hours. The SSG might use the answers to bucket the application as high, medium, or low risk. Because a risk questionnaire can be easy to game, it’s important to put some spot checking for validity and accuracy into place. An overreliance on self-reporting or automation can render this activity impotent.",
      "resources"  : [],
      "objective"  : "have a lightweight approach to risk classification and prioritization ",
      "proof"      : ""
    },
    "AA.2.1": {
      "description": "The SSG defines and documents a process for architecture analysis and applies it in the design reviews it conducts. The process includes a standardized approach for thinking about attacks and security properties, and the associated risk. The process is defined rigorously enough that people outside the SSG can be taught to carry it out. Particular attention should be paid to documentation of both the architecture under review and any security flaws uncovered. Tribal knowledge doesn’t count as a defined process. Microsoft’s STRIDE and Cigital’s ARA are examples of this process. Note that even these two methodologies for architecture analysis have evolved greatly over time. Make sure to access up-to-date sources for architecture analysis information because many early publications are outdated and no longer apply.",
      "resources"  : [],
      "objective"  : "model objects ",
      "proof"      : ""
    },
    "AA.2.2": {
      "description": "AA processes use an agreed-upon format for describing architecture, including a means for representing data flow. This format, combined with an architecture analysis process, makes architecture analysis tractable for people who are not security experts. A standard architecture description can be enhanced to provide an explicit picture of information assets that require protection. Standardized icons that are consistently used in UML diagrams, Visio templates, and whiteboard squiggles are especially useful.",
      "resources"  : [],
      "objective"  : "promote a common language for describing architecture ",
      "proof"      : ""
    },

    "AA.3.1": {
      "description": "Software architects throughout the organization lead the architecture analysis process most of the time. The SSG still might contribute to architecture analysis in an advisory capacity or under special circumstances. This activity requires a well-understood and well-documented architecture analysis process. Even in that case, consistency is very difficult to attain because breaking architectures requires so much experience.",
      "resources"  : [],
      "objective"  : "build capabilities organization-wide ",
      "proof"      : ""
    },
    "AA.3.2": {
      "description": "Failures identified during architecture analysis are fed back to the security design committee so that similar mistakes can be prevented in the future through improved design patterns (see SFD3.1 Form a review board or central committee to approve and maintain secure design patterns). Security design patterns can interact in surprising ways that break security. The architecture analysis process should be applied even when vetted design patterns are in standard use.",
      "resources"  : [],
      "objective"  : "build proactive security architecture ",
      "proof"      : ""
    },
    "AA.3.3": {
      "description": "Make the SSG available as an AA resource or mentor.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },

    "CR.1.2": {
      "description": "The SSG performs an ad hoc code review for high-risk applications in an opportunistic fashion. For example, the SSG might follow up the design review for high-risk applications with a code review. At higher maturity levels, replace ad hoc targeting with a systematic approach. SSG review could involve the use of specific tools and services, or it might be manual.",
      "resources"  : [],
      "objective"  : "review high-risk applications opportunistically ",
      "proof"      : ""
    },
    "CR.1.4": {
      "description": "Incorporate static analysis into the code review process to make code review more efficient and more consistent. The automation doesn’t replace human judgment, but it does bring definition to the review process and security expertise to reviewers who are not security experts. A firm may use an external service vendor as part of a formal code review process for software security. This service should be explicitly connected to a larger SSDL applied during software development and not just “check the security box” on the path to deployment.",
      "resources"  : [],
      "objective"  : "drive efficiency/consistency with automation ",
      "proof"      : ""
    },
    "CR.1.5": {
      "description": "Code review is a mandatory release gate for all projects under the SSG’s purview. Lack of code review or unacceptable results will stop the release train. While all projects must undergo code review, the review process might be different for different kinds of projects. The review for low-risk projects might rely more heavily on automation and the review for high-risk projects might have no upper bound on the amount of time spent by reviewers. In most cases, a code review gate with a minimum acceptable standard forces projects that don’t pass to be fixed and re-evaluated before they ship.",
      "resources"  : [],
      "objective"  : "find bugs earlier ",
      "proof"      : ""
    },
    "CR.1.6": {
      "description": "The bugs found during code review are tracked in a centralized repository. This repository makes it possible to do summary reporting and trend reporting for the organization. The SSG can use the reports to demonstrate progress and drive the training curriculum (see SM2.5 Identify metrics and use them drive budgets). Code review information can be incorporated into a CSO-level dashboard that includes feeds from other parts of the security organization. Likewise, code review information can be fed into a development-wide project tracking system that rolls up several diverse software security feeds (for example, penetration tests, security testing, black box testing, white box testing, etc.). Don’t forget that individual bugs make excellent training examples.",
      "resources"  : [],
      "objective"  : "know which bugs matter (for training) ",
      "proof"      : ""
    },

    "CR.2.5": {
      "description": "Mentors are available to show developers how to get the most out of code review tools. If the SSG is most skilled with the tools, it could use office hours to help developers establish the right configuration or get started interpreting results. Alternatively, someone from the SSG might work with a development team for the duration of the first review they perform. Centralized use of a tool can be distributed into the development organization over time through the use of tool mentors.",
      "resources"  : [],
      "objective"  : "make most efficient use of tools ",
      "proof"      : ""
    },
    "CR.2.6": {
      "description": "Customize static analysis to improve efficiency and reduce false positives. Use custom rules to find errors specific to the organization’s coding standards or custom middleware. Turn off checks that aren’t relevant. The same group that provides tool mentoring will likely spearhead the customization. Tailored rules can be explicitly tied to proper usage of technology stacks in a positive sense and avoidance of errors commonly encountered in a firm’s code base in a negative sense.",
      "resources"  : [],
      "objective"  : "drive efficiency/reduce false positives ",
      "proof"      : ""
    },
    "CR.2.7": {
      "description": " Use a top N bugs list (real data preferred).",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "CR.3.2": {
      "description": "Combine assessment results so that multiple analysis techniques feed into one reporting and remediation process. The SSG might write scripts to invoke multiple detection techniques automatically and combine the results into a format that can be consumed by a single downstream review and reporting solution. Analysis engines may combine static and dynamic analysis. The tricky part of this activity is normalizing vulnerability information from disparate sources that use conflicting terminology. In some cases, a CWE-like approach can help with nomenclature. Combining multiple sources helps drive better informed risk mitigation decisions.",
      "resources"  : [],
      "objective"  : "combine assessment techniques ",
      "proof"      : ""
    },
    "CR.3.3": {
      "description": "When a new kind of bug is found, the SSG writes rules to find it and uses the rules to identify all occurrences of the new bug throughout the entire codebase. It‘s possible to eradicate the bug type entirely without waiting for every project to reach the code review portion of its lifecycle. A firm with only a handful of software applications will have an easier time with this activity than firms with a very large number of large apps.",
      "resources"  : [],
      "objective"  : "handle new bug classes in an already scanned codebase ",
      "proof"      : ""
    },
    "CR.3.4": {
      "description": "Automated code review is used to identify dangerous code written by malicious in-house developers or outsource providers. Examples of malicious code that could be targeted include backdoors, logic bombs, time bombs, nefarious communication channels, obfuscated program logic, and dynamic code injection. Although out-of-the-box automation might identify some generic malicious-looking constructs, custom rules for static analysis tools used to codify acceptable, and unacceptable code patterns in the organization’s codebase will quickly become a necessity. Manual code review for malicious code is a good start, but is insufficient to complete this activity.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "CR.3.5": {
      "description": "Enforce coding standards.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "ST.1.1": {
      "description": "The QA team goes beyond functional testing to perform basic adversarial tests. They probe simple edge cases and boundary conditions. No attacker skills required. When QA understands the value of pushing past standard functional testing using acceptable input, they begin to move slowly toward “thinking like a bad guy.” A discussion of boundary value testing leads naturally to the notion of an attacker probing the edges on purpose. What happens when you enter the wrong password over and over?",
      "resources"  : [],
      "objective"  : "execute adversarial tests beyond functional ",
      "proof"      : ""
    },
    "ST.1.3": {
      "description": "Testers target declarative security mechanisms derived from requirements and security features. For example, a tester could try to access administrative functionality as an unprivileged user or verify that a user account becomes locked after some number of failed authentication attempts. For the most part, security features can be tested in a similar fashion to other software features. Security mechanisms based on requirements such as account lockout, transaction limitations, entitlements, and so on are also tested. Of course, software security is not security software, but getting started with features is easy.",
      "resources"  : [],
      "objective"  : "start security testing in familiar functional territory ",
      "proof"      : ""
    },
    "ST.2.1": {
      "description": "The organization uses one or more black box security testing tools as part of the quality assurance process. The tools are valuable because they encapsulate an attacker’s perspective, albeit in a generic fashion. Tools such as IBM Security AppScan or HP WebInspect are relevant for web applications, and fuzzing frameworks such as Codenomicon are applicable for most network protocols. In some situations, other groups might collaborate with the SSG to apply the tools. For example, a testing team could run the tool, but come to the SSG for help interpreting the results. Regardless of who runs the black box tool, the testing should be properly integrated into the QA cycle of the SSDL.",
      "resources"  : [],
      "objective"  : "use encapsulated attacker perspective ",
      "proof"      : ""
    },
    "ST.2.4": {
      "description": "The SSG routinely shares results from security reviews with the QA department. Over time, QA engineers learn the security mindset. Using security results to inform and evolve particular testing patterns can be a powerful mechanism leading to better security testing. This activity benefits from an engineering-focused QA function that is highly technical.",
      "resources"  : [],
      "objective"  : "facilitate security mindset ",
      "proof"      : ""
    },
    "ST.2.5": {
      "description": "Security tests run alongside functional tests as part of automated regression testing. The same automation framework houses both. Security testing is part of the routine. Security tests can be driven from abuse cases identified earlier in the lifecycle or tests derived from creative tweaks of functional tests.",
      "resources"  : [],
      "objective"  : "include security testing in regression ",
      "proof"      : ""
    },
    "ST.2.6": {
      "description": "Test automation engineers customize a fuzzing framework to the organization’s APIs. They could begin from scratch or use an existing fuzzing toolkit, but customization goes beyond creating custom protocol descriptions or file format templates. The fuzzing framework has a built-in understanding of the application interfaces it calls into. Test harnesses developed explicitly for particular applications can make good places to integrate fuzz testing.",
      "resources"  : [],
      "objective"  : "teach tools about your code ",
      "proof"      : ""
    },
    "ST.3.3": {
      "description": "Testers use architecture analysis results to direct their work. For example, if architecture analysis concludes, “the security of the system hinges on the transactions being atomic and not being interrupted partway through,” then torn transactions will be become a primary target in adversarial testing. Adversarial tests like these can be developed according to risk profile—high-risk flaws first.",
      "resources"  : [],
      "objective"  : "probe risk claims directly ",
      "proof"      : ""
    },
    "ST.3.4": {
      "description": "Testers measure the code coverage of their security tests to identify code that isn’t being exercised. Code coverage drives increased security testing depth. Standard-issue black box testing tools achieve exceptionally low coverage, leaving a majority of the software under test unexplored. Don’t let this happen to your tests. Using standard measurements for coverage such as function coverage, line coverage, or multiple condition coverage is fine.",
      "resources"  : [],
      "objective"  : "drive testing depth ",
      "proof"      : ""
    },
    "ST.3.5": {
      "description": "Testing begins to incorporate test cases based on abuse cases. Testers move beyond verifying functionality and take on the attacker’s perspective. For example, testers might systematically attempt to replicate incidents from the organization’s history. Abuse and misuse cases based on the attacker’s perspective can also be driven from security policies, attack intelligence and guidelines. This turns the corner from testing features to attempting to break the software under test.",
      "resources"  : [],
      "objective"  : "move beyond functional testing to attacker's perspective ",
      "proof"      : ""
    },
    "PT.1.1": {
      "description": "Many organizations aren’t willing to address software security until there’s unmistakable evidence that the organization isn’t somehow magically immune to the problem. If security has not been a priority, external penetration testers can demonstrate that the organization’s code needs help. Penetration testers could be brought in to break a high-profile application to make the point. Over time, the focus of penetration testing moves from “I told you our stuff was broken” to a smoke test and sanity check done before shipping. External penetration testers bring a new set of eyes to the problem.",
      "resources"  : [],
      "objective"  : "demonstrate that your organization's code needs help too ",
      "proof"      : ""
    },
    "PT.1.2": {
      "description": "Penetration testing results are fed back to development through established defect management or mitigation channels, and development responds using their defect management and release process. The exercise demonstrates the organization’s ability to improve the state of security. Many firms are beginning to emphasize the critical importance of not just identifying but, more importantly, fixing security problems. One way to ensure attention is to add a security flag to the bug tracking and defect management system. Evolving DevOps and integrated team structures do not eliminate the need for formalized defect management systems.",
      "resources"  : [],
      "objective"  : "fix what you find to show real progress ",
      "proof"      : ""
    },
    "PT.1.3": {
      "description": "The organization creates an internal penetration testing capability that uses tools. This capability can be part of the SSG or part of a specialized and trained team elsewhere in the organization. The tools improve efficiency and repeatability of the testing process. Tools can include off-the-shelf products, standard issue network penetration tools that understand the application layer, and hand-written scripts.",
      "resources"  : [],
      "objective"  : "create internal capability ",
      "proof"      : ""
    },
    "PT.2.2": {
      "description": "Penetration testers, whether internal or external, use all available information about their target. Penetration testers can do deeper analysis and find more interesting problems when they have source code, design documents, architecture analysis results, and code review results. Give penetration testers everything you have created throughout the SSDL and ensure they use it. If your penetration tester doesn’t ask for the code, you need a new penetration tester.",
      "resources"  : [],
      "objective"  : "promote deeper analysis ",
      "proof"      : ""
    },
    "PT.2.3": {
      "description": "Periodically test all applications in the SSG’s purview according to an established schedule, which could be tied to the calendar or to the release cycle. The testing serves as a sanity check and helps ensure yesterday’s software isn’t vulnerable to today’s attacks. High-profile applications might get a penetration test at least once a year. One important aspect of periodic testing is to make sure that the problems identified in a penetration test are actually fixed and they don’t creep back into the build.",
      "resources"  : [],
      "objective"  : "sanity check constantly ",
      "proof"      : ""
    },
    "PT.3.1": {
      "description": "The organization uses external penetration testers to do deep-dive analysis for critical projects and to introduce fresh thinking into the SSG. These testers are experts and specialists; they keep the organization up to speed with the latest version of the attacker’s perspective and have a track record for breaking the type of software being tested. Skilled penetration testers will always break a system. The question is whether they demonstrate new kinds of thinking about attacks that can be useful when designing, implementing, and hardening new systems. Creating new types of attacks from threat intelligence and abuse cases prevents checklist-driven approaches that only look for known types of problems.",
      "resources"  : [],
      "objective"  : "keep up with edge of attacker's perspective ",
      "proof"      : ""
    },
    "PT.3.2": {
      "description": "The SSG either creates penetration testing tools or adapts publicly-available tools so they can more efficiently and comprehensively attack the organization’s systems. Tools improve the efficiency of the penetration testing process without sacrificing the depth of problems the SSG can identify. Tools that can be tailored are always preferable to generic tools. This activity considers both the depth of tests and their scope.",
      "resources"  : [],
      "objective"  : "automate for efficiency without losing depth ",
      "proof"      : ""
    },
    "SE.1.1": {
      "description": "The organization monitors the input to software it runs in order to spot attacks. For web code, a web application firewall (WAF) can do the job. The SSG could be responsible for the care and feeding of the system. Incident response is not part of this activity. Defanged WAFs that write log files can be useful if somebody reviews the logs periodically. On the other hand, a WAF that’s unmonitored makes no noise when an application falls in the woods.",
      "resources"  : [],
      "objective"  : "watch software ",
      "proof"      : ""
    },
    "SE.1.2": {
      "description": "The organization provides a solid foundation for software by ensuring that host and network security basics are in place. It is common for operations security teams to be responsible for duties such as patching operating systems and maintaining firewalls. Doing software security before network security is like putting on your pants before putting on your underwear.",
      "resources"  : [],
      "objective"  : "provide a solid host/network foundation for software ",
      "proof"      : ""
    },
    "SE.2.2": {
      "description": "The SSDL requires the creation of an installation guide to help deployment teams and operators install and configure the software securely. If special steps are required to ensure a deployment is secure, the steps are outlined in the installation guide. The guide should include discussion of COTS components. In some cases, installation guides are distributed to customers who buy the software. Evolving DevOps and integrated team structures do not eliminate the need for written guides. Of course, secure by default is always the best way to go.",
      "resources"  : [],
      "objective"  : "guide operations on application needs ",
      "proof"      : ""
    },
    "SE.2.4": {
      "description": "The organization uses code signing for software published across trust boundaries. Code signing is particularly useful for protecting the integrity of software that leaves the organization’s control, such as shrink-wrapped applications or thick clients. The fact that some mobile platforms require application code to be signed does not indicate institutional use of code signing.",
      "resources"  : [],
      "objective"  : "protect apps (or parts of apps) that are published over trust boundaries ",
      "proof"      : ""
    },
    "SE.3.2": {
      "description": "To protect intellectual property and make exploit development harder, the organization erects barriers to reverse engineering. Obfuscation techniques could be applied as part of the production build and release process. Employing platform-specific controls such as Data Execution Prevention (DEP), Safe Structured Error Handling (SafeSEH), and Address Space Layout Randomization (ASLR) can make exploit development more difficult.",
      "resources"  : [],
      "objective"  : "protect IP and make exploit development harder ",
      "proof"      : ""
    },
    "SE.3.3": {
      "description": "The organization monitors the behavior of production software looking for misbehavior and signs of attack. This activity goes beyond host and network monitoring to look for problems that are specific to the software, such as indications of fraud. Intrusion detection and anomaly detection systems at the application level may focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates.",
      "resources"  : [],
      "objective"  : "watch software ",
      "proof"      : ""
    },
    "SE.3.4": {
      "description": "The organization monitors the behavior of production software looking for misbehavior and signs of attack. This activity goes beyond host and network monitoring to look for problems that are specific to the software, such as indications of fraud. Intrusion detection and anomaly detection systems at the application level may focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates.",
      "resources"  : [],
      "objective"  : "watch software ",
      "proof"      : ""
    },
    "SE.3.5": {
      "description": "The organization monitors the behavior of production software looking for misbehavior and signs of attack. This activity goes beyond host and network monitoring to look for problems that are specific to the software, such as indications of fraud. Intrusion detection and anomaly detection systems at the application level may focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates.",
      "resources"  : [],
      "objective"  : "watch software ",
      "proof"      : ""
    },
    "SE.3.6": {
      "description": "The organization monitors the behavior of production software looking for misbehavior and signs of attack. This activity goes beyond host and network monitoring to look for problems that are specific to the software, such as indications of fraud. Intrusion detection and anomaly detection systems at the application level may focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates.",
      "resources"  : [],
      "objective"  : "watch software ",
      "proof"      : ""
    },
    "SE.3.7": {
      "description": "The organization monitors the behavior of production software looking for misbehavior and signs of attack. This activity goes beyond host and network monitoring to look for problems that are specific to the software, such as indications of fraud. Intrusion detection and anomaly detection systems at the application level may focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates.",
      "resources"  : [],
      "objective"  : "watch software ",
      "proof"      : ""
    },
    "CMVM.1.1": {
      "description": "The SSG is prepared to respond to an incident and is regularly included in the incident response process. The group either creates its own incident response capability or regularly interfaces with the organization’s existing incident response team. A regular meeting between the SSG and the incident response team can keep information flowing in both directions. In many cases, software security initiatives have evolved from incident response teams who began to realize that software vulnerabilities were the bane of their existence.",
      "resources"  : [],
      "objective"  : "know what to do when something bad happens ",
      "proof"      : ""
    },
    "CMVM.1.2": {
      "description": "Defects identified through operations monitoring are fed back to development and used to change developer behavior. The contents of production logs can be revealing (or can reveal the need for improved logging). In some cases, providing a way to enter incident triage data into an existing bug tracking system (many times making use of a special security flag) seems to work. The idea is to close the information loop and make sure security problems get fixed. In the best of cases, processes in the SSDL can be improved based on operational data.",
      "resources"  : [],
      "objective"  : "use ops data to change dev behavior ",
      "proof"      : ""
    },
    "CMVM.2.1": {
      "description": "The organization can make quick code changes when an application is under attack. A rapid-response team works in conjunction with the application owners and the SSG to study the code and the attack, find a resolution, and push a patch into production. Often, the emergency response team is the development team itself. Fire drills don’t count; a well-defined process is required. A process that has never been used may not actually work.",
      "resources"  : [],
      "objective"  : "be able to fix apps when they are under direct attack ",
      "proof"      : ""
    },
    "CMVM.2.2": {
      "description": "Defects found in operations are fed back to development, entered into established defect management systems and tracked through the fix process. This capability could come in the form of a two-way bridge between the bug finders and the bug fixers. Make sure the loop is closed completely. Setting a security flag in the bug-tracking system can help facilitate tracking.",
      "resources"  : [],
      "objective"  : "use ops data to change dev behavior ",
      "proof"      : ""
    },
    "CMVM.2.3": {
      "description": "The organization has a map of its software deployments. If a piece of code needs to be changed, operations can reliably identify all of the places where the change needs to be installed. Sometimes common components shared between multiple projects are noted so that when an error occurs in one application, other applications that share the same components can be fixed as well.",
      "resources"  : [],
      "objective"  : "know where the code is ",
      "proof"      : ""
    },
    "CMVM.3.1": {
      "description": "The organization fixes all instances of each software bug found during operations and not just the small number of instances that have triggered bug reports. This requires the ability to reexamine the entire codebase when new kinds of bugs come to light (see CR3.3 Build capability for eradicating specific bugs from entire codebase). One way to approach this is to create a rule set that generalizes a deployed bug into something that can be scanned for using automated code review.",
      "resources"  : [],
      "objective"  : "learn from operational experience ",
      "proof"      : ""
    },
    "CMVM.3.2": {
      "description": "Experience from operations leads to changes in the SSDL. The SSDL is strengthened to prevent the reintroduction of bugs found during operations. To make this process systematic, the incident response post mortem could include a “feedback to SSDL” step. This works best when root cause analysis pinpoints where in the SDLC an error could have been introduced or slipped by uncaught. An ad hoc approach is not sufficient.",
      "resources"  : [],
      "objective"  : "use ops data to change dev behavior ",
      "proof"      : ""
    },
    "CMVM.3.3": {
      "description": "The SSG simulates high-impact software security crises to ensure software incident response capabilities minimize damage. Simulations could test for the ability to identify and mitigate specific threats or, in other cases, could begin with the assumption that a critical system or service is already compromised and evaluate the organization’s ability to respond. When simulations model successful attacks, an important question to consider is the time period required to clean up. Regardless, simulations must focus on security-relevant software failure and not on natural disasters or other types of emergency response drills. If the data center is burning to the ground, the SSG won’t be among the first responders.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    },
    "CMVM.3.4": {
      "description": "The organization solicits vulnerability reports from external researchers and pays a bounty for each verified and accepted vulnerability received. Payouts typically follow a sliding scale linked to multiple factors, such as vulnerability type (e.g., remote code execution is worth $10,000 versus CSRF is worth $750), exploitability (demonstrable exploits command much higher payouts), or specific services and software versions (widely-deployed or critical services warrant higher payouts). Ad hoc or short-duration activities, such as capture-the-flag contests, do not count.",
      "resources"  : [],
      "objective"  : "{...}",
      "proof"      : ""
    }
  }
}