<p>Since you reference the handling of vulnerabilities specifically in your question, I'll speak to this regarding how we handle this within our organization and group of companies.</p>

<p>We have an Information Security department who are responsible to monitoring and detecting vulnerabilities. You could think of this team as being responsible to technical information security management. When vulnerabilities are detected using regular scan with tools such as <a href="https://www.tenable.com/products/nessus-vulnerability-scanner" rel="nofollow noreferrer">Nessus</a> or published <a href="https://www.us-cert.gov/ncas/alerts" rel="nofollow noreferrer">US-CERT</a> by the information security community, this team passes these vulnerabilities to each Information Security Officer within the group.</p>

<p>The Information Security Officer, who is responsible and accountable for risk management, is tasked at a high level with:</p>

<ul>
<li>Establishing Information Security Policy, Standards, Procedures and Guidelines</li>
<li>Promoting Information Security Awareness</li>
<li>Completing Information Security Assessments and Audits</li>
</ul>

<p>Having received the information regarding vulnerabilities, the Information Security Officer evaluates the vulnerability, determines the criticality of the vulnerability and it's impact on the business applications and environment. This information is then given to the appropriate Development Manager.</p>

<p>Development Managers are responsible and accountable for supplier and vendor management. Business Applications are allocated by business domain to various Development Managers. The Development Managers work with either a vendor and/or their own Scrum team to resolve the vulnerabilities withing their domain. Should specialist advice be required, this is provided by the Information Security Officer.</p>

<p>Regarding your possible options.</p>

<ul>
<li>Scrum teams might well lack the organizational clout to negotiate and compel vendors to address vulnerabilities quickly. It's also unlikely that the scrum teams themselves would have been in a position to ensure that all the correct legal clauses have been put into the vendor and supplier contracts to ensure that there is an obligation to handle vulnerabilities within a given SLA.</li>
<li>Maintaining a central function ought to work to a degree, however as you point out they would lack the full context. Three tiers of management, covering three different aspects will address this short coming.</li>
<li>A 3rd Party automated service will be able to alert you to vulnerabilities, but it will not necessarily be able to correlate those results to a specific business application, and as a consequence a given vendor or supplier. You will still need individual people to manage this aspect.</li>
</ul>

CC BY-SA 3.0
2017-08-26T11:49:17.257Z
2017-08-26T11:49:17.257Z
Grant Durr
<p>Within a traditional separate Development and Operations organisations, procedures and processes are put in place to ensure that relationships between software vendors and suppliers are maintained. These relationships exist so that when for example a vulnerability is discovered operations teams are able to identify the business impact and mitigate appropriately.</p>

<p>If that organisation was built around ITIL service management principals then they would likely be doing one or all of the following:</p>

<ul>
<li><a href="https://wiki.en.it-processmaps.com/index.php/Supplier_Management" rel="noreferrer">Supplier Management</a></li>
<li><a href="http://www.gartner.com/it-glossary/vendor-management" rel="noreferrer">Vendor Management</a></li>
<li><a href="https://wiki.en.it-processmaps.com/index.php/Risk_Management" rel="noreferrer">Risk Management</a></li>
</ul>

<p>With the assumption that the Operations role doesn't exist as a separate entity within a DevOps enabled organisation, how is an organisation collectively or severally meant to maintain supplier/vendor relationships so that when a <a href="http://thehackernews.com/2017/02/google-windows-vulnerability.html" rel="noreferrer">vulnerability is publicised</a> the teams can respond by reaching out to the vendor to understand remediation and mitigation actions.</p>

<p>Conceivably we could:</p>

<ul>
<li>Ask all of the Scrum teams to own their vendor relationships and act accordingly, this seems scalable but at the cost of a high overhead across an organization.</li>
<li>Maintain a central function responsible for these relationships, this central function may not have the full context the the Cross-functional teams have.</li>
<li>Use a 3rd Party automated service to scan infrastructure and applications to maintain a dynamic inventory which can be assessed for known vulnerabilities, this however doesn't actually maintain a relationship with vendors and is only as good as it's database of known vulnerabilities.</li>
</ul>

<p>What strategies do you use?</p>

<terminology><operating-model>
What processes enable software vendor/supplier management in a DevOps way of working?
Richard Slater
# What processes enable software vendor/supplier management in a DevOps way of working?

(Asked by: username_0 on 2017-04-24)

Within a traditional separate Development and Operations organisations, procedures and processes are put in place to ensure that relationships between software vendors and suppliers are maintained. These relationships exist so that when for example a vulnerability is discovered operations teams are able to identify the business impact and mitigate appropriately.

If that organisation was built around ITIL service management principals then they would likely be doing one or all of the following:

* [Supplier Management](https://wiki.en.it-processmaps.com/index.php/Supplier_Management)
* [Vendor Management](http://www.gartner.com/it-glossary/vendor-management)
* [Risk Management](https://wiki.en.it-processmaps.com/index.php/Risk_Management)

With the assumption that the Operations role doesn't exist as a separate entity within a DevOps enabled organisation, how is an organisation collectively or severally meant to maintain supplier/vendor relationships so that when a [vulnerability is publicised](http://thehackernews.com/2017/02/google-windows-vulnerability.html) the teams can respond by reaching out to the vendor to understand remediation and mitigation actions.

Conceivably we could:

* Ask all of the Scrum teams to own their vendor relationships and act accordingly, this seems scalable but at the cost of a high overhead across an organization.
* Maintain a central function responsible for these relationships, this central function may not have the full context the the Cross-functional teams have.
* Use a 3rd Party automated service to scan infrastructure and applications to maintain a dynamic inventory which can be assessed for known vulnerabilities, this however doesn't actually maintain a relationship with vendors and is only as good as it's database of known vulnerabilities.

What strategies do you use?

**Tags:** terminology, operating-model


---

## 1 answers

### Answer by username_1 on 2017-08-26. Score: 2 | Accepted answer

Since you reference the handling of vulnerabilities specifically in your question, I'll speak to this regarding how we handle this within our organization and group of companies.

We have an Information Security department who are responsible to monitoring and detecting vulnerabilities. You could think of this team as being responsible to technical information security management. When vulnerabilities are detected using regular scan with tools such as [Nessus](https://www.tenable.com/products/nessus-vulnerability-scanner) or published [US-CERT](https://www.us-cert.gov/ncas/alerts) by the information security community, this team passes these vulnerabilities to each Information Security Officer within the group.

The Information Security Officer, who is responsible and accountable for risk management, is tasked at a high level with:

* Establishing Information Security Policy, Standards, Procedures and Guidelines
* Promoting Information Security Awareness
* Completing Information Security Assessments and Audits

Having received the information regarding vulnerabilities, the Information Security Officer evaluates the vulnerability, determines the criticality of the vulnerability and it's impact on the business applications and environment. This information is then given to the appropriate Development Manager.

Development Managers are responsible and accountable for supplier and vendor management. Business Applications are allocated by business domain to various Development Managers. The Development Managers work with either a vendor and/or their own Scrum team to resolve the vulnerabilities withing their domain. Should specialist advice be required, this is provided by the Information Security Officer.

Regarding your possible options.

* Scrum teams might well lack the organizational clout to negotiate and compel vendors to address vulnerabilities quickly. It's also unlikely that the scrum teams themselves would have been in a position to ensure that all the correct legal clauses have been put into the vendor and supplier contracts to ensure that there is an obligation to handle vulnerabilities within a given SLA.
* Maintaining a central function ought to work to a degree, however as you point out they would lack the full context. Three tiers of management, covering three different aspects will address this short coming.
* A 3rd Party automated service will be able to alert you to vulnerabilities, but it will not necessarily be able to correlate those results to a specific business application, and as a consequence a given vendor or supplier. You will still need individual people to manage this aspect.


---

