Assets management

[keithdouglas]

Most organizations have a "software assets management" group or similar. This organization and your organization's Enterprise Architecture should be involved, as should any "business relationship management" units to coordinate the use of software in general - OSS should be a possibility but there is a danger of allowing subject areas or their "portfolio" programmers jumping the gun on what software to use.

[gcharest]

Very good point, we already have a lot of work being done around proprietary software licence management and "asset" tracking. I'm pretty sure we could leverage current practices for the COTS-like OSS software.

Regarding the OSS components in use for development projects, that might need a more structured environment and set of processes in departments.

If we were to have a centralized development and VCS platform offering such capabilities, I think we would all benefit from it. @sboots @ptd-tbs @obrien-j @CalvinRodo

[keithdouglas]

I'm trying to create the software/application security parts of our "structured environment" but run continually into these other considerations. Hard work! :)

[obrien-j]

My only caution in any of this is falling into the 'perfect is the enemy of good' trap.

Central control more often than not fails. I am not however suggesting anarchy, but perhaps an understanding on both sides of the discussion, and an agreement to work towards a common goal.

If you can clearly identify what 'challenges' you perceive, then often times, the development community will gladly help you resolve them, if it gets them the flexibility they desire.

Suggest you take a look at Jeff McAffer's presentation from the Open First day, https://canada-ca.github.io/ofd-joep/assets/pdf/Jeff%20McAffer%20Open%20source%20at%20scale.pdf , as he's done a very good job of describing the balance that I'd suggest we need to seek.

[keithdouglas]

I am attempting to coordinate discussions with all parties - to decentralize a little. I agree that one cannot have authorization committees directly approve every last library and python package or to SA&A huge systems "waterfall style" (would be nice to have an Agile SA&A process ...)

Depending on your organization, however, the level to which one can "slack the reins" is subject to what the OWASP folks call "software assurance maturity". I have yet to use their stuff formally but informally it has proved useful at least as a conversation starter within IT security.

[CalvinRodo]

Oh you are talking about Asset Management in regards to libraries and not just software.

My experience as a developer is that you have any sort of approval committee that needs to review libraries you are going to end up with developers copy and pasting code from Open Source Projects or even worse stack overflow.

Developers don't have the time to wait for a group of people assess the libraries they want to use.

A more pragmatic and realistic solution is to risk manage, put in place something that can act as an on-prem proxy for the various package managers out there and leverage it for dependency asset management and vulnerability scanning of those dependencies.

There are some COTS products that can be purchased for this purpose or something can be hacked together for a build pipeline using various Open Source Tools.

[gcharest]

Yes, @jeffmcaffer presentation was really putting a lot of importance to removing barriers and automating as much as possible the workflow for the developers. Not doing so basically lead to @CalvinRodo point about people just circumventing the process in place to accelerate things.

There's a possibility to do things well and it probably starts small :wink: