Mentors View: Aligning Your Team and Your Powers for Success

Editor's Notes

• #2: Introduction Name CSE - Work with organizations to build better component practices such that they can improve their software supply chain management Today, I am going to.. =================
• #4: In general, there are 2 main requirements when deploying software and this is especially true with component management Tooling - Non-negotiable, like any other practice, developers can’t succeed unless equipped with the right tools.  The major keys with tooling include: Integrate where developers work, not the other way around Needs to operate at the pace of development or it becomes a bottleneck Process - The process you put in place allows you to enable that tooling to developers (Eg education), set clear expectations (Eg What is required of me?) and at the end of the day monitor and track usage / progress So, when I walk into an organization.  The first goal is understanding where we are starting from: What is the culture? Education? Tooling – What are we transitioning from? Current processes – Have developers had to adhere to prior checks within the SDLC
• #5: Initial success metrics. What does first value mean to you? Small/quick wins BOM Remediation Enforcement Bring in the right people Subject matter experts Organizational support – change of technology, process requires top down executive support. Ability to mandate usage? Enterprise success metrics. Provide examples Education How do developers get integrated How do they get educated What can they reference for assistance Who can they contact when encountering an issue Track – At the end of the day, someone needs to provide approval – What do they need to see?
• #6: When bringing multiple groups together, we must understand and accept that they have different priorities. Establishing this and the interactions between them is key --------------------------------------------- People How many are developers? How many are managers? How many work in operations, tool chain? Governance? OSS How many people are familiar with the concept of dependencies? What languages?  Java, npm, NuGet? Tooling How many here use a repository manager? Process How many have a manual review process for component approvals? How many go straight to the internet for components? How many have application checks at release time?
• #7: Successful tooling integrates where the developers are performing their work – IDE, CI, Repository Manager Tooling / Technology is not the sole answer – Process must be established around it to set expectations, train developers and track progress to continually make improvements
• #8: All parties on the same playing field of information Empower developers to make better choices Initiate constructive conversations ------------------ https://www.linkedin.com/pulse/agile-transformation-what-went-wrong-pradeep-bindra Implement Agile in an Agile way. When leading organizations through the transformation from traditional software development to Agile, it is a great idea to start small. Identify only a few pilot teams that are ready to volunteer and are enthusiastic. This will not only help to focus on early, small successes in adapting Agile to the organization but it will also increase trust and help identify the barriers (organizational and personal) to fostering greater change. Starting small will help to quickly surface the delivery of business value, reduce risk, and prepare people to move the organization to greater levels of agility.
• #9: You as the project team have the responsibility to ensure the tooling is generating valid issues Developers should remediate, not validate Lack of clarity leads to frustration, bottlenecks and lack of trust in the tooling ---------------------------- A developer’s options or path forward should be as obvious as possible What are the enforcement points? What do I HAVE to fix to be able to release to product? Ex. Fix the red violations Administration team should be easily accessible for questions ------------------ Limit the mandatory issues developers receive Too many issues results in tool antipathy A threat threshold should be defined Threat threshold should be communicated clearly
• #10: Anyone who has ever used security or quality tooling.. Static Source Code Not every issue can be critical – Sensory overload How do you know where to start? Skepticism around the tool Cost of doing business
• #11: This is more actionable Threat level denotes priority - Drives developer actions Advice: Fix the red Tip: Especially where expectations didn’t exist before – devs cannot immediately comply – pandora’s box – time period for grandfathering violations, cannot fix everything on day one
• #12: This is the process that every organization goes through Discovery – Understand how my org builds and releases software. - Big need Inventory – I need to be able to identify all my applications and all the components within my applications. Do you know where they are? What they contain? Policy – Once inventory is collected, I need to identify the things that I care about Mitigation – Once you have identified the policy, you need to push this out to devs for mitigation Enforcement – This may be necessary to eliminate high risk in production application. Recommendation is to warn early and fail late, but even still, take care with this decision
• #14: Question – What is the main purpose of a policy? Answer – To drive intended behavior no smoking? speed limit? – You are either following it or not – Yes or No don’t run with scissors password strength? Point - Policies don’t have to be these big, complicated things, they should be simple and concise rule(s) for defining guidelines around open source component consumption
• #15: For Open Source Components, we generally see 4 main types of policy Security Legal Architecture Match State How do we decide on the exact guidelines – subject matter experts
• #16: Policy characteristics Precise Contextual Actionable Continuous Fast
• #21: Keep in mind Each organization is at a different starting point Different groups may sponsor the initiative, driving different directives In general, we see Most organizations begin with small goals, given the maturity of their open source supply chain Most organizations start with Auditing to better understand the scope of the problem Most organizations warn early, and fail late As always, some organizations have a compelling event as to why they purchased Eg Find struts
• #23: Are you driving the intended behavior? Are developers making better choices? Is the software quality going up and productivity going up?
• #26: Application Health Check is an easy no-cost way to run a report and get real results so that you can have better visibility into all of the components that make up your application. Your app does not leave your network. A one-way fingerprint is generated from the components in your app and compared against Sonatype’s Data Services to identify a Bill of Materials.
• #29: Introduction Name CSE - Work with organizations to build better component practices such that they can improve their software supply chain management Background – Static Source Code Analysis Today, I am going to..