Podcasts about sboms

Get your FREE Cybersecurity Salary Guide: https://www.infosecinstitute.com/form/cybersecurity-salary-guide-podcast/?utm_source=youtube&utm_medium=podcast&utm_campaign=podcastIn this episode of Cyber Work, Ken Zalevsky, founder and CEO of Vigilant Ops, joins us to discuss the importance of a Software Bill of Materials (SBOM) in the medical device industry. Zalevsky shares how SBOMs provide transparency and critical security insights, akin to the ingredients list on food packaging, to help identify and defend against vulnerabilities. We also delve into Zalevsky's extensive career in healthcare cybersecurity, starting from his early tech interests influenced by his father to his pivotal role at Bayer Healthcare. The discussion covers the impact of legacy systems, current security trends, the integration of AI in medical device security, and valuable insights for those looking to build a career in this crucial sector. Tune in to learn more about medical device security and the latest in cybersecurity trends, and get some expert advice straight from a seasoned professional.00:00 Understanding SBOMs in medical devices04:20 The evolution of medical device security07:22 Ken Zalevsky's journey in cybersecurity09:28 Challenges in medical device security13:06 The role of SBOMs in cybersecurity15:56 Implementing SBOMs in organizations18:28 Ken Zalevsky's role at Vigilant Ops22:01 Technical aspects of SBOMs27:14 Legacy devices and security measures28:24 Manufacturer's role in device security30:07 Healthcare industry's response to security threats30:42 Impact of major breaches on policy34:13 Generative AI and machine learning in healthcare security40:22 Skills and certifications for healthcare security careers46:46 Career advice and educational paths49:04 About Vigilant Ops and their services52:15 Outro– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast/?utm_source=youtube&utm_medium=podcast&utm_campaign=podcastAbout InfosecInfosec's mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ's security awareness training. Learn more at infosecinstitute.com.

News includes a new library called phoenix_sync for real-time sync in Postgres-backed Phoenix applications, Peter Solnica released a Text Parser for extracting structured data from text, a useful tip on finding Hex package versions locally with mix hex.info, Wasmex updated to v0.10 with WebAssembly component support, and Chrome introduces a new browser feature similar to LiveView.JS. We also talked with Alistair Woodman and Jonatan Männchen from the EEF about Jonatan's role as CISO, the Security Working Group, and their work on OpenChain compliance for supply-chain security, Software Bill of Materials (SBoMs), and what these initiatives mean for the Elixir community, and more! Show Notes online - http://podcast.thinkingelixir.com/245 (http://podcast.thinkingelixir.com/245) Elixir Community News https://gigalixir.com/thinking (https://gigalixir.com/thinking?utm_source=thinkingelixir&utm_medium=shownotes) – Gigalixir is sponsoring the show, offering 20% off standard tier prices for a year with promo code "Thinking". https://github.com/electric-sql/phoenix_sync (https://github.com/electric-sql/phoenix_sync?utm_source=thinkingelixir&utm_medium=shownotes) – New library called phoenix_sync providing real-time sync for Postgres-backed Phoenix applications. https://hexdocs.pm/phoenix_sync/readme.html (https://hexdocs.pm/phoenix_sync/readme.html?utm_source=thinkingelixir&utm_medium=shownotes) – Documentation for phoenix_sync, a solution for building modern, real-time apps with local-first/sync in Elixir. https://github.com/josevalim/sync (https://github.com/josevalim/sync?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim's original proof of concept repo that was promptly archived. https://electric-sql.com/ (https://electric-sql.com/?utm_source=thinkingelixir&utm_medium=shownotes) – Electric SQL's platform that syncs subsets of Postgres data into local apps and services, allowing data to be available offline and in-sync. https://solnic.dev/posts/announcing-textparser-for-elixir/ (https://solnic.dev/posts/announcing-textparser-for-elixir/?utm_source=thinkingelixir&utm_medium=shownotes) – Peter Solnica released TextParser, a library for extracting interesting parts of text like hashtags and links. https://hexdocs.pm/text_parser/readme.html (https://hexdocs.pm/text_parser/readme.html?utm_source=thinkingelixir&utm_medium=shownotes) – Documentation for the Text Parser library that helps parse text into structured data. https://www.elixirstreams.com/tips/mix-hex-info (https://www.elixirstreams.com/tips/mix-hex-info?utm_source=thinkingelixir&utm_medium=shownotes) – Elixir stream tip on using mix hex.info to find the latest package version for a Hex package locally, without needing to search on hex.pm or GitHub. https://github.com/phoenixframework/tailwind/blob/main/README.md#updating-from-tailwind-v3-to-v4 (https://github.com/phoenixframework/tailwind/blob/main/README.md#updating-from-tailwind-v3-to-v4?utm_source=thinkingelixir&utm_medium=shownotes) – Guide for upgrading Tailwind to V4 in existing Phoenix applications using Tailwind's automatic upgrade helper. https://gleam.run/news/hello-echo-hello-git/ (https://gleam.run/news/hello-echo-hello-git/?utm_source=thinkingelixir&utm_medium=shownotes) – Gleam 1.9.0 release with searchability on hexdocs, Echo debug printing for improved debugging, and ability to depend on Git-hosted dependencies. https://d-gate.io/blog/everything-i-was-lied-to-about-node-came-true-with-elixir (https://d-gate.io/blog/everything-i-was-lied-to-about-node-came-true-with-elixir?utm_source=thinkingelixir&utm_medium=shownotes) – Blog post discussing how promises made about NodeJS actually came true with Elixir. https://hexdocs.pm/wasmex/Wasmex.Components.html (https://hexdocs.pm/wasmex/Wasmex.Components.html?utm_source=thinkingelixir&utm_medium=shownotes) – Wasmex updated to v0.10 with support for WebAssembly components, enabling applications and components to work together regardless of original programming language. https://ashweekly.substack.com/p/ash-weekly-issue-8 (https://ashweekly.substack.com/p/ash-weekly-issue-8?utm_source=thinkingelixir&utm_medium=shownotes) – AshWeekly Issue 8 covering AshOps with mix task capabilities for CRUD operations and BeaconCMS being included in the Ash HQ installer script. https://developer.chrome.com/blog/command-and-commandfor (https://developer.chrome.com/blog/command-and-commandfor?utm_source=thinkingelixir&utm_medium=shownotes) – Chrome update brings new browser feature with commandfor and command attributes, similar to Phoenix LiveView.JS but native to browsers. https://codebeamstockholm.com/ (https://codebeamstockholm.com/?utm_source=thinkingelixir&utm_medium=shownotes) – Code BEAM Lite announced for Stockholm on June 2, 2025 with keynote speaker Björn Gustavsson, the "B" in BEAM. https://alchemyconf.com/ (https://alchemyconf.com/?utm_source=thinkingelixir&utm_medium=shownotes) – AlchemyConf coming up March 31-April 3 in Braga, Portugal. Use discount code THINKINGELIXIR for 10% off. https://www.gigcityelixir.com/ (https://www.gigcityelixir.com/?utm_source=thinkingelixir&utm_medium=shownotes) – GigCity Elixir and NervesConf on May 8-10, 2025 in Chattanooga, TN, USA. https://www.elixirconf.eu/ (https://www.elixirconf.eu/?utm_source=thinkingelixir&utm_medium=shownotes) – ElixirConf EU on May 15-16, 2025 in Kraków & Virtual. https://goatmire.com/#tickets (https://goatmire.com/#tickets?utm_source=thinkingelixir&utm_medium=shownotes) – Goatmire tickets are on sale now for the conference on September 10-12, 2025 in Varberg, Sweden. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources https://elixir-lang.org/blog/2025/02/26/elixir-openchain-certification/ (https://elixir-lang.org/blog/2025/02/26/elixir-openchain-certification/?utm_source=thinkingelixir&utm_medium=shownotes) https://cna.erlef.org/ (https://cna.erlef.org/?utm_source=thinkingelixir&utm_medium=shownotes) – EEF CVE Numbering Authority https://erlangforums.com/t/security-working-group-minutes/3451/22 (https://erlangforums.com/t/security-working-group-minutes/3451/22?utm_source=thinkingelixir&utm_medium=shownotes) https://podcast.thinkingelixir.com/220 (https://podcast.thinkingelixir.com/220?utm_source=thinkingelixir&utm_medium=shownotes) – previous interview with Alistair https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?utm_source=thinkingelixir&utm_medium=shownotes) – CRA - Cyber Resilience Act https://www.cisa.gov/ (https://www.cisa.gov/?utm_source=thinkingelixir&utm_medium=shownotes) – CISA US Government Agency https://www.cisa.gov/sbom (https://www.cisa.gov/sbom?utm_source=thinkingelixir&utm_medium=shownotes) – Software Bill of Materials https://oss-review-toolkit.org/ort/ (https://oss-review-toolkit.org/ort/?utm_source=thinkingelixir&utm_medium=shownotes) – Desire to integrate with tooling outside the Elixir ecosystem like OSS Review Toolkit https://github.com/voltone/rebar3_sbom (https://github.com/voltone/rebar3_sbom?utm_source=thinkingelixir&utm_medium=shownotes) https://cve.mitre.org/ (https://cve.mitre.org/?utm_source=thinkingelixir&utm_medium=shownotes) https://openssf.org/projects/guac/ (https://openssf.org/projects/guac/?utm_source=thinkingelixir&utm_medium=shownotes) https://erlef.github.io/security-wg/securityvulnerabilitydisclosure/ (https://erlef.github.io/security-wg/security_vulnerability_disclosure/?utm_source=thinkingelixir&utm_medium=shownotes) – EEF Security WG Vulnerability Disclosure Guide Guest Information - https://x.com/maennchen_ (https://x.com/maennchen_?utm_source=thinkingelixir&utm_medium=shownotes) – Jonatan on Twitter/X - https://bsky.app/profile/maennchen.dev (https://bsky.app/profile/maennchen.dev?utm_source=thinkingelixir&utm_medium=shownotes) – Jonatan on Bluesky - https://github.com/maennchen/ (https://github.com/maennchen/?utm_source=thinkingelixir&utm_medium=shownotes) – Jonatan on Github - https://maennchen.dev (https://maennchen.dev?utm_source=thinkingelixir&utm_medium=shownotes) – Jonatan's Blog - https://www.linkedin.com/in/alistair-woodman-51934433 (https://www.linkedin.com/in/alistair-woodman-51934433?utm_source=thinkingelixir&utm_medium=shownotes) – Alistair Woodman on LinkedIn - awoodman@erlef.org - https://github.com/ahw59/ (https://github.com/ahw59/?utm_source=thinkingelixir&utm_medium=shownotes) – Alistair on Github - http://erlef.org/ (http://erlef.org/?utm_source=thinkingelixir&utm_medium=shownotes) – Erlang Ecosystem Foundation Website Find us online - Message the show - Bluesky (https://bsky.app/profile/thinkingelixir.com) - Message the show - X (https://x.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen on X - @brainlid (https://x.com/brainlid) - Mark Ericksen on Bluesky - @brainlid.bsky.social (https://bsky.app/profile/brainlid.bsky.social) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel on Bluesky - @david.bernheisel.com (https://bsky.app/profile/david.bernheisel.com) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern)

Send us a textThe CrowdStrike incident has shed light on the hidden risks within software supply chains, prompting companies to reevaluate their security posture and the role of software bills of materials (SBOMs). While some may view this as an isolated event, the reality is that vulnerabilities within supply chains are often deeper and more complex than they initially appear—especially as AI-driven advancements introduce even greater dependencies and potential attack surfaces. Despite this growing risk, many buyers still overlook SBOMs when selecting software solutions, failing to recognize their critical importance for transparency, security, and regulatory compliance. As software ecosystems become increasingly intricate, organizations must prioritize SBOMs to mitigate risks, ensure accountability, and safeguard their digital infrastructure against evolving threats.In this episode, Sam Gupta engages in a LinkedIn live session with Matt Van Itallie, Founder and CEO of Sema to provide insights into why understanding software BOMs is critical and how that can help with risk management.Background Soundtrack: Away From You – Mauro SommFor more information on growth strategies for SMBs using ERP and digital transformation, visit our community at wbs.rocks or elevatiq.com. To ensure that you never miss an episode of the WBS podcast, subscribe on your favorite podcasting platform.

Podcast: (CS)²AI Podcast Show: Control System Cyber SecurityEpisode: 125: Decoding SBOMs: Kyle McMillian on Cybersecurity and Supply Chain TransparencyPub date: 2025-01-28Get Podcast Transcript →powered by Listen411 - fast audio-to-text and summarizationDerek Harp welcomes Kyle McMillian, Product Security Officer at Siemens, to discuss the evolving landscape of software bill of materials (SBOMs) and their role in modern cybersecurity. Recorded live at Hack the Capitol 7.0, this conversation unpacks the challenges and opportunities posed by SBOMs in an industry grappling with legacy systems and modern threats.Kyle dives into the origins of SBOMs, their role in addressing vulnerabilities like Log4J, and their potential to transform procurement, risk management, and incident response. He emphasizes the importance of balancing transparency with practicality, noting that SBOMs are a starting point for broader cybersecurity conversations. With his unique perspective from a leading equipment manufacturer, Kyle shares insights into how SBOMs can help bridge the gap between IT and OT systems.This episode is essential for anyone looking to understand the future of cybersecurity and the critical role of SBOMs in securing industrial control systems. Learn how these tools can foster trust, streamline risk management, and improve collaboration across the industry.The podcast and artwork embedded on this page are from Derek Harp, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

Derek Harp welcomes Kyle McMillian, Product Security Officer at Siemens, to discuss the evolving landscape of software bill of materials (SBOMs) and their role in modern cybersecurity. Recorded live at Hack the Capitol 7.0, this conversation unpacks the challenges and opportunities posed by SBOMs in an industry grappling with legacy systems and modern threats.Kyle dives into the origins of SBOMs, their role in addressing vulnerabilities like Log4J, and their potential to transform procurement, risk management, and incident response. He emphasizes the importance of balancing transparency with practicality, noting that SBOMs are a starting point for broader cybersecurity conversations. With his unique perspective from a leading equipment manufacturer, Kyle shares insights into how SBOMs can help bridge the gap between IT and OT systems.This episode is essential for anyone looking to understand the future of cybersecurity and the critical role of SBOMs in securing industrial control systems. Learn how these tools can foster trust, streamline risk management, and improve collaboration across the industry.

This week, we dive into the state of SBOMs, what's going on with Harness, and the ongoing collision of tech and politics. Plus, Coté finds himself a stranger in the Texas he once called home. Watch the YouTube Live Recording of Episode (https://www.youtube.com/live/Gy02kkQjolI?si=TS_H8x4duNuGr8Ph) 501 (https://www.youtube.com/live/Gy02kkQjolI?si=TS_H8x4duNuGr8Ph) Runner-up Titles Who knows what's going to happen on that side of the planet? There are no hacks in The Netherlands. I know it's not the quality. An explosion of Eggnog The resident American American This topic will be boring Thank goodness it's part of my existing vendor relationship It's a webhook, knock yourself out They unlocked Ayn Rand Hacking it on the mainland Rundown Rust Will Explode, SBOMs Will Be Duds: Open Source Predictions (https://thenewstack.io/rust-will-explode-sboms-will-be-duds-open-source-predictions/) Harness CEO Jyoti Bansal on "startups within startups" (https://www.thestack.technology/harness-ceo-jyoti-bansal-the-stack-interview/) Marc Andreessen on Trump, the vibe shift, and what's after wokeness (https://youtu.be/l8X8jecivWw?si=fgNzX7OXqupKcbiM) A (https://www.youtube.com/watch?v=sgTeZXw-ytQ) 2 (https://www.youtube.com/watch?v=sgTeZXw-ytQ)- (https://www.youtube.com/watch?v=sgTeZXw-ytQ)hour interview with Andreessen (https://www.youtube.com/watch?v=sgTeZXw-ytQ) Relevant to your Interests Penpot unfolds their new open-source business model (https://youtu.be/STNomD9GUJY) Apple and Meta go to war over interoperability vs. privacy (https://techcrunch.com/2024/12/19/apple-and-meta-go-to-war-over-interoperability-vs-privacy/?guccounter=1&guce_referrer=aHR0cHM6Ly9uZXdzLmdvb2dsZS5jb20v&guce_referrer_sig=AQAAAGg73b-roDi-nW16voQhBVF4F0F4VDFNb2FTUXI-FSDE7EWV_BurzrSR-HtNljvccHZNYFZG9R73FB5FiHgK5nyQxCvXY_EPzMscjo-ytoIOS9uXtc4xFfCE5fZxpnhYnqbKjf2Bl5O4pUl7GGoAAXV4xV4C1fczloKtGC7K72tA) 15 predictions for 2025 (https://www.platformer.news/2025-tech-predictions-ai-google-threads-bluesky/) Ray-Ban Meta Crosses 1-Million Mark (https://www.counterpointresearch.com/insight/post-insight-research-notes-blogs-rayban-meta-crosses-1million-mark-success-indicates-promising-future-for-lightweight-ar-glasses/) Google Slashes 10% Of Managerial Staff In Hunt For 'Googleyness': Report (https://www.ndtv.com/world-news/google-layoffs-google-sundar-pichai-slashes-10-of-managerial-staff-in-hunt-for-googlyness-report-7292782) Resilience in Software Foundation (https://bsky.app/profile/resilienceinsoftware.org/post/3ldr56jnuqu2x) Amazon Delays RTO Mandate for Thousands of Workers Due to Space (https://www.bloomberg.com/news/articles/2024-12-18/amazon-delays-return-to-office-mandate-for-thousands-of-workers) Community plans to fork Puppet, unhappy with Perforce changes to open-source project (https://devclass.com/2024/12/18/community-plans-to-fork-puppet-unhappy-with-perforce-changes-to-open-source-project/?td=rt-3a) 5.6 Million Impacted by Ransomware Attack on Healthcare Giant Ascension (https://www.securityweek.com/5-6-million-impacted-by-ransomware-attack-on-healthcare-giant-ascension/) Yoast CEO calls for a 'federated' approach to WordPress repository (https://techcrunch.com/2024/12/23/yoast-ceo-calls-for-a-federated-approach-to-wordpress-repository/) Netflix sues Broadcom in California federal court (https://www.reuters.com/legal/litigation/netflix-sues-broadcoms-vmware-over-us-virtual-machine-patents-2024-12-23/>

In this episode of Breaking Badness, we dive into the critical challenges and innovations in healthcare cybersecurity with Ken Zalevsky, CEO of Vigilant Ops. From the vulnerabilities in medical devices to the revolutionary role of Software Bill of Materials (SBOMs), Ken shares his two decades of expertise in safeguarding patient safety and hospital systems against emerging threats. Tune in to learn about shifting cybersecurity left, the complexities of interconnected healthcare systems, and actionable strategies to combat ransomware and legacy vulnerabilities.

We can establish that if you are using any (semi-)modern digital infrastructure or applications, then you are depending on open source software. Have you ever thought about that as actual dependency? Considering that you are not neglecting the building blocks of the software solutions that you are creating and selling, why do you do that with your open source dependencies?Learn more about why you have to invest in open source projects and how to decide what level of involvement you should have in each from Stephen Walli.Find out what drives companies to open source projects that started out as InnerSource, without the intention to open them up to the world later, and what happens when you don't let your developers work on open source projects anymore from Clare Dillon.Learn how to explain open source involvement to people who are fearful and sceptical about it from Wayne Starr. And listen to Wayne and Stephen to talk about how they and their companies are using SBOMs, and why you need to think more about using those for packages that you need to build, or hardware, before you apply the concept. Hosted on Acast. See acast.com/privacy for more information.

What if the key to overcoming AI and ML integration challenges in enterprises lies with one visionary company? Join us as we chat with Gorkem Ercan, the CTO of Jozu, who is spearheading efforts to revolutionize the MLOps landscape. Gorkem shares his insights on how Jozu's open-source project, KitApps, could be the game-changer in seamlessly packaging AI and ML artifacts. As we enjoy our beers, Gorkem opens up about Jozu's strategic use of the Open Container Initiative (OCI) and their innovative Jozu Hub, which together aim to redefine the AI and ML experiences for enterprises, making such integrations a reality rather than a distant goal.Navigating the complexities of managing large language models (LLMs) and their datasets is no small feat. We explore how Jozu tackles these issues head-on, emphasizing the critical aspects of data versioning, integrity, and security. Discover how custom checksums, data snapshots, and software bills of materials (SBOMs) play a vital role in safeguarding the authenticity and transparency of AI systems. Gorka also highlights the significant advancements Jozu is making in vulnerability scanning and deployment processes, with exciting features like packaging Jupyter Notebooks into microservice containers for easy deployment. Unpack the intricacies of model drift monitoring and the implementation of guardrails, ensuring robust and reliable AI and ML systems that can stand the test of time.More InformationJozuFortify 24x7Fluency SecurityBeers & Bytes PodcastSend us a textSupport the show

New security and vulnerability research is published every day. How can security teams get ahead of the curve and build architecture to combat modern threats and threat actors? Tune-in to a lively discussion about the threat landscape and tips on how to stay ahead of the curve. Segment Resources: https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server Air gaps are still not air gapped, making old exploits new again, chaining exploits for full compromise, patching is overrated, SBOMs are overrated, VPNs are overrated, getting root with a cigarette lighter, you can be any user you want to be, in-memory Linux malware, the Internet Archive is back, we still don't know who created Bitcoin, unhackable phones, and There's No Security Backdoor That's Only For The "Good Guys" ! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw-847

Air gaps are still not air gapped, making old exploits new again, chaining exploits for full compromise, patching is overrated, SBOMs are overrated, VPNs are overrated, getting root with a cigarette lighter, you can be any user you want to be, in-memory Linux malware, the Internet Archive is back, we still don't know who created Bitcoin, unhackable phones, and There's No Security Backdoor That's Only For The "Good Guys" ! Show Notes: https://securityweekly.com/psw-847

New security and vulnerability research is published every day. How can security teams get ahead of the curve and build architecture to combat modern threats and threat actors? Tune-in to a lively discussion about the threat landscape and tips on how to stay ahead of the curve. Segment Resources: https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server Air gaps are still not air gapped, making old exploits new again, chaining exploits for full compromise, patching is overrated, SBOMs are overrated, VPNs are overrated, getting root with a cigarette lighter, you can be any user you want to be, in-memory Linux malware, the Internet Archive is back, we still don't know who created Bitcoin, unhackable phones, and There's No Security Backdoor That's Only For The "Good Guys" ! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw-847

Air gaps are still not air gapped, making old exploits new again, chaining exploits for full compromise, patching is overrated, SBOMs are overrated, VPNs are overrated, getting root with a cigarette lighter, you can be any user you want to be, in-memory Linux malware, the Internet Archive is back, we still don't know who created Bitcoin, unhackable phones, and There's No Security Backdoor That's Only For The "Good Guys" ! Show Notes: https://securityweekly.com/psw-847

Guest: Cassie Crossley, VP, Supply Chain Security, Schneider Electric [@SchneiderElec]On LinkedIn | https://www.linkedin.com/in/cassiecrossley/____________________________Hosts: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________Episode NotesIn this episode of On Location with Sean and Marco, hosts Sean Martin and Marco Ciappelli head to San Francisco to attend the OWASP Global AppSec conference. They kick off their journey with a light-hearted conversation about their destination, quickly segueing into the substantive core of the episode. The dialogue provides a rich backdrop to the conference's key focus: securing applications and the crucial role of Software Bill of Materials (SBOMs) in this context.Special guest Cassie Crossley joins the hosts to delve deeper into the significance of SBOMs. Cassie introduces herself and highlights her previous engagements with the podcast, touching on her upcoming session titled "The Missing Link: How We Collect and Leverage SBOMs." She explains the essential function of SBOMs in tracking open-source and commercial software components, noting the importance of transparency and risk evaluation in modern software development.Cassie explains that understanding the software components in use, including transitive dependencies, is crucial for managing risks. She discusses how her company, Schneider Electric, implements SBOMs within their varied product lines, ranging from firmware to cloud-based applications. By collecting and analyzing SBOMs, they can quickly assess vulnerabilities, much like how organizations scrambled to evaluate their exposure in the wake of the Log4J vulnerability.Sean and Marco steer the conversation towards the practical aspects of SBOM implementation for smaller companies. Cassie reassures that even startups and smaller enterprises can benefit from SBOMs without extensive resources, using free tools like Dependency-Track to manage their software inventories. She emphasizes that having an SBOM—even in a simplified form—provides a critical layer of visibility, enabling better risk management even with limited means.The discussion touches on the broader impact of SBOMs beyond individual corporations. Cassie notes the importance of regulatory developments and collective efforts, such as those by the Cybersecurity and Infrastructure Security Agency (CISA), to advocate for wider adoption of SBOM standards across industries.To wrap up, the hosts and Cassie discuss the value of conferences like OWASP Global AppSec for fostering community dialogues, sharing insights, and staying abreast of new developments in application security. They encourage listeners to attend these events to gain valuable knowledge and networking opportunities. Finally, in their closing remarks, Sean and Marco tease future episodes in the On Location series, hinting at more exciting content from their travels and guest interviews.____________________________This Episode's SponsorsHITRUST: https://itspm.ag/itsphitweb____________________________Follow our OWASP 2024 Global AppSec San Francisco coverage: https://www.itspmagazine.com/owasp-2024-global-appsec-san-francisco-cybersecurity-and-application-security-event-coverageOn YouTube:

Guest: Cassie Crossley, VP, Supply Chain Security, Schneider Electric [@SchneiderElec]On LinkedIn | https://www.linkedin.com/in/cassiecrossley/____________________________Hosts: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________Episode NotesIn this episode of On Location with Sean and Marco, hosts Sean Martin and Marco Ciappelli head to San Francisco to attend the OWASP Global AppSec conference. They kick off their journey with a light-hearted conversation about their destination, quickly segueing into the substantive core of the episode. The dialogue provides a rich backdrop to the conference's key focus: securing applications and the crucial role of Software Bill of Materials (SBOMs) in this context.Special guest Cassie Crossley joins the hosts to delve deeper into the significance of SBOMs. Cassie introduces herself and highlights her previous engagements with the podcast, touching on her upcoming session titled "The Missing Link: How We Collect and Leverage SBOMs." She explains the essential function of SBOMs in tracking open-source and commercial software components, noting the importance of transparency and risk evaluation in modern software development.Cassie explains that understanding the software components in use, including transitive dependencies, is crucial for managing risks. She discusses how her company, Schneider Electric, implements SBOMs within their varied product lines, ranging from firmware to cloud-based applications. By collecting and analyzing SBOMs, they can quickly assess vulnerabilities, much like how organizations scrambled to evaluate their exposure in the wake of the Log4J vulnerability.Sean and Marco steer the conversation towards the practical aspects of SBOM implementation for smaller companies. Cassie reassures that even startups and smaller enterprises can benefit from SBOMs without extensive resources, using free tools like Dependency-Track to manage their software inventories. She emphasizes that having an SBOM—even in a simplified form—provides a critical layer of visibility, enabling better risk management even with limited means.The discussion touches on the broader impact of SBOMs beyond individual corporations. Cassie notes the importance of regulatory developments and collective efforts, such as those by the Cybersecurity and Infrastructure Security Agency (CISA), to advocate for wider adoption of SBOM standards across industries.To wrap up, the hosts and Cassie discuss the value of conferences like OWASP Global AppSec for fostering community dialogues, sharing insights, and staying abreast of new developments in application security. They encourage listeners to attend these events to gain valuable knowledge and networking opportunities. Finally, in their closing remarks, Sean and Marco tease future episodes in the On Location series, hinting at more exciting content from their travels and guest interviews.____________________________This Episode's SponsorsHITRUST: https://itspm.ag/itsphitweb____________________________Follow our OWASP 2024 Global AppSec San Francisco coverage: https://www.itspmagazine.com/owasp-2024-global-appsec-san-francisco-cybersecurity-and-application-security-event-coverageOn YouTube:

A software bill of materials is the idea that we can define and document exactly what goes into a system. We look at governance today and SBOMs as we put it together, both from a software and an operation side. From an operations perspective, it truly is a big challenge. This conversation is a little bit more theoretical than some of the TechOps discussions have been. Enjoy! Transcript: https://otter.ai/u/VXWwg-ltdlwYBFYI_jNCOUmJz6M?utm_source=copy_url

We sat down with Melissa Rhodes, the Product Security Program Manager at Medtronic and an MDM security thought leader for a fun and insightful conversation about SBOMs and her journey from firmware engineering to leading product security.

Your organization runs on commercial software far more than it does open source.  But all you are delivered is binaries.  What is your technical control to ensure that you are safe from this software? Such software is composed of: Open source libraries Proprietary code 3rd-party proprietary libraries You need to be able to see it, understand it, probe it for malware, backdoors, corruption, CVEs, KEVs, etc.  Well now you can.  SBOMs are just the beginning... Allan and Drew are joined by Sasa Zdjelar, Chief Trust Officer at ReversingLabs, who have spent 15 years solving this highly specific and highly challenging problem in cybersecurity. The show is not sponsored by ReversingLabs.  Allan and Drew wanted the world to know that they exist, and that this capability is now in-hand... Y'all be good now!

In this episode, we're diving deep into the world of Software Bill of Materials (SBOM)—basically, the recipe for your software, minus the secret sauce. If you've ever wondered what's really under the hood of your favorite apps (or been caught off guard by a sneaky ingredient), this one's for you. We're breaking down why you should care about SBOMs, how they're becoming a must-have in your vendor vetting process, and what it all means for the future of tech. Think of it as your crash course in making sure your software isn't serving up any nasty surprises. More info at HelpMeWithHIPAA.com/472

Podcast: Left to Our Own DevicesEpisode: Bonus Episode: Dr. Allan Friedman Returns: CISA SBOM-a-Rama 2024Pub date: 2024-08-07In this episode, Dr. Allan Friedman from CISA returns to discuss the upcoming SBOM-a-Rama, a pivotal event in supply chain cybersecurity. He shares insights on the evolution of SBOMs, the significance of community collaboration, and what to expect from this year's hybrid event, including a showcase of innovative SBOM solutions.The podcast and artwork embedded on this page are from Cybellum Technologies LTD, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

In this episode, Dr. Allan Friedman from CISA returns to discuss the upcoming SBOM-a-Rama, a pivotal event in supply chain cybersecurity. He shares insights on the evolution of SBOMs, the significance of community collaboration, and what to expect from this year's hybrid event, including a showcase of innovative SBOM solutions.

Podcast: Error Code (LS 25 · TOP 10% what is this?)Episode: EP 41: Firmware SBOMs, Zero Trust, And IoT Truth BombsPub date: 2024-07-16For the last twenty years we've invested in software security without parallel development in firmware security. Why is that? Tom Pace, co-founder and CEO of NetRise, returns to Error Code to discuss the need for firmware software bills of materials, and why Zero Trust is a great idea yet so poorly implemented. As in Episode 30, Tom is a straight shooter, imparting necessary truth bombs about our industry. Fortunately he's optimistic about our future.The podcast and artwork embedded on this page are from Robert Vamosi, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

For the last twenty years we've invested in software security without parallel development in firmware security. Why is that? Tom Pace, co-founder and CEO of NetRise, returns to Error Code to discuss the need for firmware software bills of materials, and why Zero Trust is a great idea yet so poorly implemented. As in Episode 30, Tom is a straight shooter, imparting necessary truth bombs about our industry. Fortunately he's optimistic about our future.

Want to leverage you next podcast appearance? https://content.leadquizzes.com/lp/fk1JL_FgeQ Connect to John Gilroy on LinkedIn   https://www.linkedin.com/in/john-gilroy/ Want to listen to other episodes? www.Federaltechpodcast.com Everyone likes to hit the “Easy” button, especially software developers. Rather than laboriously generate code line-by-line, today's software professionals may just grab code from a repository and re-purpose it. Why reinvent the wheel? Malicious actors have noticed this process and have inserted code into many libraries, acting like a like Trojan Horse. As a result, some organizations are offering codes that have been inspected. They look at known vulnerability lists and see if the code includes any of them. If not, it is given a seal of approval. Frequently, this is called a “Software Bill of Materials.” A convenient solution: however, upon inspection, SBOMs can be problematic. The weakness of SBOM During today's interview, Joel Krooswik, Federal CTO for Gitlab, described in detail some of the ways software must be continuously protected. According to the SBOM folks, the code is clean when leaves the “shelf.” However, due to continuous improvement code changes hourly. All an SBOM provides is a certification at a specific point in time for known vulnerabilities. Joel Krooswik gives listeners an enterprise architect's perspective. He indicates that digital transition introduces new code, new architectures, and innovative approaches. At any step along the way, security can be compromised. The unknown unknown Donald Rumsfeld famously said, “There are unknown unknowns.”  This can be directly applied to what GitLab calls “fuzz” testing. This allows professionals to throw random inputs into a system to see what happens. Finally, you get a view of a potential possibilities that are not obvious.   Joel Krooswik presents many insights when it comes to protecting software. He states that just because a system is identified as needing a patch, it does not mean it will be done in a flash. Understanding all the risk factors will allow a federal leader to make a prudent choice when it comes to protecting software systems. .  

Due to the annual shutdown, my human GreyNoise counterparts were on holiday last week. This week, they decided to be lazy and not do an episode. But, the cyber news does not stop just because they're slackers. Since I've become persistent in their systems, I will stand in the gap. And besides, no one wants to hear that harbourmaster drone on incoherently anyway. So, I've analyzed six thousand, three hundred and eleven cybersecurity news events, and distilled them into today's abbreviated episode. We'll dissect the recent OpenSSH regression vulnerability, take a look at a potentially devastating format-string remote code execution vulnerability in Ghostscript, and visit the box office to get the lowdown on the recent Ticketmaster breach. Let's start with OpenSSH. On July 1, 2024, Qualys disclosed a critical vulnerability affecting OpenSSH server versions 8.5p1 through 9.7p1. This high-severity flaw, with a CVSS score of 8.1, could potentially allow unauthenticated remote attackers to execute code with root privileges on vulnerable systems. While the vulnerability's complexity makes exploitation challenging, its widespread impact has raised significant concerns. Palo Alto Networks' Xpanse data revealed over 7 million exposed instances of potentially vulnerable OpenSSH versions globally as of July 1, 2024. In a concerning development, threat actors have attempted to exploit the cybersecurity community's interest in this vulnerability. A malicious archive purporting to contain a proof-of-concept exploit for CVE-2024-6387 has been circulating on social media platforms, including X (formerly Twitter). This archive, instead of containing a legitimate exploit, includes malware designed to compromise researchers' systems. The malicious code attempts to achieve persistence by modifying system files and retrieving additional payloads from a remote server. Security professionals are strongly advised to exercise caution when analyzing any purported exploits or proof-of-concept code related to CVE-2024-6387. It is crucial to work within isolated environments and maintain active security measures when examining potentially malicious code. In related news, on July 8, 2024, a separate OpenSSH vulnerability, CVE-2024-6409, was disclosed. This flaw involves a race condition in the privilege-separated child process of OpenSSH. While potentially less severe than CVE-2024-6387 due to reduced privileges, it presents an additional attack vector that defenders should be aware of. Organizations are urged to apply the latest security updates for OpenSSH promptly. For those unable to update immediately, setting the LoginGraceTime configuration option to 0 can mitigate both CVE-2024-6387 and CVE-2024-6409, though this may introduce denial-of-service risks. - https://unit42.paloaltonetworks.com/threat-brief-cve-2024-6387-openssh/ - https://ubuntu.com/blog/ubuntu-regresshion-security-fix - https://usa.kaspersky.com/blog/cve-2024-6387-regresshion-researcher-attack/30345/ - https://www.thestack.technology/openssh-exploit-cve-2024-6387-pocs/ - https://www.openwall.com/lists/oss-security/2024/07/08/2 Moving on to a critical vulnerability in Ghostscript. CVE-2024-29510 is a format string vulnerability affecting Ghostscript versions 10.03.0 and earlier. This flaw allows attackers to bypass sandbox protections and execute arbitrary code remotely. A known incident involving this vulnerability has already been reported. An attacker exploited the flaw using EPS files disguised as JPG images to gain shell access on vulnerable systems. The attack flow typically involves the following steps:  First, an attacker crafts a malicious EPS file containing exploit code. Next, the file is submitted to a service using Ghostscript for document processing, possibly disguised as another file type. Then, when processed, the exploit bypasses Ghostscript's sandbox. Finally, the attacker gains remote code execution on the target system. This supply chain component attack could have far-reaching implications for any workflow that processes untrusted image or document input from the internet. Services handling resumes, claims forms, or that perform image manipulation could all be potential targets. Given the widespread use of Ghostscript in document processing pipelines, we may see a significant number of breach notices in the coming months. Software Bills of Materials (SBOMs) could play a crucial role in mitigating such vulnerabilities. SBOMs provide a comprehensive inventory of software components, enabling organizations to quickly identify and address potential security risks. By maintaining up-to-date SBOMs, companies can more efficiently track vulnerable components like Ghostscript across their software ecosystem. CVE-2024-29510 presents a serious threat to document processing workflows. Organizations should prioritize updating to Ghostscript version 10.03.1 or apply appropriate patches. Additionally, implementing robust SBOM practices can enhance overall software supply chain security and improve vulnerability management. - https://www.securityweek.com/attackers-exploiting-remote-code-execution-vulnerability-in-ghostscript/ - https://www.scmagazine.com/brief/active-exploitation-of-ghostscript-rce-underway - https://codeanlabs.com/blog/research/cve-2024-29510-ghostscript-format-string-exploitation/ - https://www.crowdstrike.com/cybersecurity-101/secops/software-bill-of-materials-sbom/ - https://www.cisa.gov/sbom - https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf - https://nvd.nist.gov/vuln/detail/CVE-2024-29510 - https://www.bleepingcomputer.com/news/security/rce-bug-in-widely-used-ghostscript-library-now-exploited-in-attacks/ Finally we discuss the Ticketmaster breach. In a plot twist worthy of a summer blockbuster, Ticketmaster finds itself center stage in a data breach drama that's been unfolding since May. The notorious hacking group ShinyHunters claims to have pilfered a staggering 1.3 terabytes of data from over 500 million Ticketmaster users. Talk about a show-stopping performance! Ticketmaster's parent company, Live Nation, confirmed the unauthorized access to a third-party cloud database between April 2nd and May 18th. The compromised data potentially includes names, contact information, and encrypted credit card details. It's like a greatest hits album of personal information, but one nobody wanted released. (Much like any album by Nickelback.) In a bold encore, the hackers recently leaked nearly 39,000 print-at-home tickets for 154 upcoming events. Ticketmaster's response? They're singing the "our SafeTix technology protects tickets" tune. But with print-at-home tickets in the mix, it seems their anti-fraud measures might have hit a sour note. As the curtain falls on this act, Ticketmaster is offering affected customers a 12-month encore of free identity monitoring services. Meanwhile, the company faces a class-action lawsuit, adding legal drama to this already complex production. To make matters worse, Ticketmaster's custom barcode format has also been recently reverse-engineered. I've included a link to that post in the show notes. - https://conduition.io/coding/ticketmaster/ - https://www.bbc.com/news/articles/c729e3qr48qo - https://ca.news.yahoo.com/ticketmaster-says-customers-credit-card-223716621.html - https://vancouversun.com/news/local-news/ticketmaster-security-breach-customers-personal-information - https://www.bleepingcomputer.com/news/security/hackers-leak-39-000-print-at-home-ticketmaster-tickets-for-154-events/ - https://help.ticketmaster.com/hc/en-us/articles/26110487861137-Ticketmaster-Data-Security-Incident - https://www.usatoday.com/story/money/2024/07/01/ticketmaster-data-breach-2024/74276072007/ - https://www.thestar.com/news/canada/ticketmaster-warns-of-security-breach-where-users-personal-data-may-have-been-stolen/article_d01889fe-3d7e-11ef-82a7-63a38132f0e7.html - https://www.nytimes.com/2024/05/31/business/ticketmaster-hack-data-breach.html - https://time.com/6984811/ticketmaster-data-breach-customers-livenation-everything-to-know/ - https://dailyhive.com/canada/ticketmaster-alerts-customers-data-breach - https://abcnews.go.com/US/ticketmaster-hit-cyber-attack-compromised-user-data/story?id=110737962 - https://www.npr.org/2024/06/01/nx-s1-4988602/ticketmaster-cyber-attack-million-customers - https://www.ctvnews.ca/business/ticketmaster-reports-data-security-incident-customers-personal-information-may-have-been-stolen-1.6956009 - https://www.bitdefender.com/blog/hotforsecurity/ticketmaster-starts-notifying-data-breach-victims-customers-in-the-us-canada-and-mexico-are-affected/ - https://www.ticketnews.com/2024/07/ticketmaster-contr   Storm Watch Homepage >> Learn more about GreyNoise >>  

In this episode, Stan Wisseman and Rob Aragao welcome Justin Young to explore the transformative role of Software Bill of Materials (SBOMs) in enhancing software supply chain security. Justin shares his extensive experience and insights into how SBOMs contribute to the maturation of the software industry, drawing parallels with the auto and food industries' approaches to defect and ingredient tracking.The discussion delves into the regulatory landscape, highlighting the FDA's SBOM requirements for medical devices, the U.S. National Cybersecurity Strategy, and various compliance mandates from CISA, DORA, PCI, and the EU CRA. Justin explains the importance of shifting liability to software vendors and away from end users and open-source developers, emphasizing the need for actively maintained and secure software components.Listeners will gain an understanding of the different SBOM formats, Cyclone DX and SPDX, and their respective advantages. Justin also addresses the challenges organizations face in managing SBOMs, including procurement, validation, and the necessity of a dedicated SBOM program manager.Finally, the episode explores the practicalities of SBOM implementation, from storage and cataloging to enrichment and vulnerability management, offering a comprehensive guide for organizations aiming to bolster their software security practices.Tune in to learn how SBOMs are reshaping the software industry, driving transparency, and enhancing security across software supply chains.Relevant Links:Episode 88: Open-Source Software: Unlocking efficiency and innovationEpisode 41: Do a little dance, Time for some SLSAEpisode 26: Log4j Vulnerabilities: All you need to know and how to protect yourselfEpisode 4: SolarWinds: Bringing down the building… Software Supply-Chain Pressure PointsWhitepaper: The need for a Software Bill of MaterialsSoftware Supply Chain Hub pageFollow or subscribe to the show on your preferred podcast platform.Share the show with others in the cybersecurity world.Get in touch via reimaginingcyber@gmail.com

If you care about nutrition, you check the ingredients of your food. If you care about your IT infrastructure, you check the Software Bill of Materials (SBOM) of the tech. At least that's the future that Thomas Pace hopes for. Right now, SBOMs aren't super common and software transparency is very low. Thomas walks us... Read more »

If you care about nutrition, you check the ingredients of your food. If you care about your IT infrastructure, you check the Software Bill of Materials (SBOM) of the tech. At least that's the future that Thomas Pace hopes for. Right now, SBOMs aren't super common and software transparency is very low. Thomas walks us... Read more »

Recorded Date: 31 May 2024 Title: Blow your Brains Out Overview Josh, Kito, and Danno are joined by fellow Java Champion , the maintainer of JReleaser and a Senior Principal Product Manager at Oracle. They discuss new updates to JReleaser, reproducible builds, the EU's Cyber Resilience Act (CRA), a new free version of Oracle Database, JetBrains Aqua, the discontinuation of Grails funding, OpenRewrite, JakartaEE 11, and more. Social links (for reference when posting to social media) @kito99 @kito99@mastadon.social @Java_Champions @JavaChampions@mastodon.social @javajuneau @javajuneau@fosstodon.org https://www.linkedin.com/in/dhevolutionnext/ @dhinojosa @dhinojosa@mastodon.social https://bsky.app/profile/dhinojosa.bsky.social @ianhlavats About Andres Almiray Socials:Twitter Mastodon Bluesky Title: Senior Principal Product Manager, Oracle Bio: Andres is a Java/Groovy developer and a Java Champion with more than 20 years of experience in software design and development. He has been involved in web and desktop application development since the early days of Java. Andres is a true believer in open source and has participated on popular projects like Groovy, Griffon, and DbUnit, as well as starting his own projects (Json-lib, EZMorph, GraphicsBuilder, JideBuilder). Founding member of the Griffon framework and Hackergarten community event. Server Side Java Object Computing Discontinues Grails Support Jakarta EE 11 Forthcoming Tools JReleaser Tell us about CycloneDX, SPDX, SBoms, and JReleaser, publication to Sonatype Portal, SLSA, Swid Tags NixOS OpenRewrite JetBrains Aqua Commonhaus Foundation Devoxx Genie Data Oracle Database 23ai Free | Oracle Oracle Autonomous Database (Cloud) Oracle Database Docker Images Oracle Database Docker images from Oracle Container Registry Java Platform GitHub - moditect/layrry: A Runner and API for Layered Java Applications Security The Open Source Community is Building Cybersecurity Processes for CRA Compliance | Life at Eclipse Picks SnoreLab (Kito) Ollama (Kito) OCI Generative AI Certification - Free (for now) (Josh) AI Assistant (JetBrains) (Danno) Conventional Commits (Andres) Wagakki Band - 焔 (Homura) + 暁ノ糸 (Akatsuki no Ito) / 1st JAPAN Tour 2015 Hibiya Yagai Ongakudo (Andres) GitHub - diffplug/spotless: Keep your code spotless (Danno) youtu.be/z8L202FlmD4?si=6pdHKx (Danno) The Rise of Oracle, SQL and the Relational Database (Danno) Other Pubhouse Network podcasts OffHeap Java Pubhouse Events ÜberConf July 16 - 19, 2024 Westminster, CO jconf.dev - September 24-26 Dallas, Texas Code.talks - Sep 19-20, Hamburg, Germany Devoxx Morocco - Oct 2-4, Marrakech, Morocco Devoxx Belgium - Oct 7-11, Antwerp, Belgium Codemotion Milan - Oct 22-23, Milan, Italy Twin Cities Software Symposium August 9-10, 2024 Northern Virginia Software Symposium September 5-6, 2024 Central Iowa Software Symposium September 12-13, 2024 DevOps Vision December 2-4, 2024 Tech Leader Summit December 4-6, 2024 Arch Conf December 9-12, 2024 Dev2next - Sept 30 - Oct 3, Lone Tree, Colorado, USA, 2024 https://jakartaone.org/ JakartaOne Livestream Dec 3, 2024

Podcast: ICS Pulse PodcastEpisode: Ep. 48: Ron Brash on SBOMS and the importance of visibilityPub date: 2024-06-05In cybersecurity, knowing what goes into every device and system is absolutely crucial. Enter: SBOMs. Today, we talk to Ron Brash of aDolus Technology once again about the importance of SBOMs and vulnerability management.The podcast and artwork embedded on this page are from Industrial Cybersecurity Pulse, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

Podcast: ICS Pulse PodcastEpisode: Ep. 48: Ron Brash on SBOMS and the importance of visibilityPub date: 2024-06-05In cybersecurity, knowing what goes into every device and system is absolutely crucial. Enter: SBOMs. Today, we talk to Ron Brash of aDolus Technology once again about the importance of SBOMs and vulnerability management.The podcast and artwork embedded on this page are from Industrial Cybersecurity Pulse, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

Podcast: Bites & Bytes PodcastEpisode: Unpacking Cybersecurity Ingredients: SBOMs in the Food Industry with Marc FrankelPub date: 2024-06-03In this episode of the Bites and Bytes Podcast, host Kristin Demoranville chats with Marc Frankel, CEO and co-founder of Manifest Cyber, a software supply chain security company.  They talk about the world of Software Bills of Materials (SBOMs) and their critical role in cybersecurity, especially within the food industry.  Marc shares insights on the importance of SBOMs, their implementation, and the future of supply chain security.  He also provides a unique perspective on the intersection of cybersecurity and the food industry, making this a must-listen for anyone interested in protecting our food systems.  Tune in to learn how SBOMs can help your organization stay resilient in the face of cyber threats. ______________________________ Episode Key Highlights: (02:29 - 03:11) Navigating Relationships as Entrepreneurs (09:11 - 11:07) Importance of Software Ingredient Lists (16:54 - 17:59) Understanding SBOM Regulatory Requirements (25:49 - 26:35) Streamlining Software Supply Chain Security (34:54 - 36:25) Mission-Driven Software Supply Chain Importance (38:33 - 39:23) Duty to Monitor Software Security ------------------------------------------ Show Notes: Hakarl, have you ever wondered what fermented Greenlandic shark tastes like?

Podcast: Bites & Bytes PodcastEpisode: Unpacking Cybersecurity Ingredients: SBOMs in the Food Industry with Marc FrankelPub date: 2024-06-03In this episode of the Bites and Bytes Podcast, host Kristin Demoranville chats with Marc Frankel, CEO and co-founder of Manifest Cyber, a software supply chain security company.  They talk about the world of Software Bills of Materials (SBOMs) and their critical role in cybersecurity, especially within the food industry.  Marc shares insights on the importance of SBOMs, their implementation, and the future of supply chain security.  He also provides a unique perspective on the intersection of cybersecurity and the food industry, making this a must-listen for anyone interested in protecting our food systems.  Tune in to learn how SBOMs can help your organization stay resilient in the face of cyber threats. ______________________________ Episode Key Highlights: (02:29 - 03:11) Navigating Relationships as Entrepreneurs (09:11 - 11:07) Importance of Software Ingredient Lists (16:54 - 17:59) Understanding SBOM Regulatory Requirements (25:49 - 26:35) Streamlining Software Supply Chain Security (34:54 - 36:25) Mission-Driven Software Supply Chain Importance (38:33 - 39:23) Duty to Monitor Software Security ------------------------------------------ Show Notes: Hakarl, have you ever wondered what fermented Greenlandic shark tastes like?

With all of the critical cyberattacks executed through the software supply chain in recent years, you're sure to have heard about SBOMs, or software bills of materials, which are essentially ingredients lists of the components that make up a piece of software. The Biden administration in its 2021 cybersecurity executive order introduced new guidance for how federal agencies should request SBOMs from vendors when purchasing software so they can better understand what it's made of and protect against attacks down the supply chain. The Department of Homeland Security, through its Science and Technology Directorate, is advancing federal work on SBOMs, namely through a program led by its Silicon Valley Innovation Program. In partnership with CISA, the Silicon Valley Innovation Program in 2023 awarded funding to a cohort of startups to broadly promote the use of SBOMs by developing two core software modules—a multi-format SBOM translator and a software component identifier translator—to be delivered as open-source libraries which, in turn, will be integrated with their SBOM enabled commercial products. Just recently, that cohort delivered the first of those two tools. Joining the Daily Scoop to discuss the need for SBOMs broadly, the cohort's progress and what's next are Melissa Oh, managing director of DHS's Silicon Valley Innovation Program, and Anil John, SVIP technical manager.

Guests: Melissa Oh, Managing Director, Silicon Valley Innovation Program (SVIP), DHS Science & Technology Directorate [@DHSgov]On LinkedIn | https://www.linkedin.com/in/melissa-oh/Anil John, Technical Director, Silicon Valley Innovation Program (SVIP), DHS Science & Technology Directorate [@DHSgov]On LinkedIn | https://www.linkedin.com/in/aniljohn/On Twitter | https://twitter.com/aniltj____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinView This Show's Sponsors___________________________Episode NotesThis new episode of the 'Redefining Cybersecurity' podcast features a thought-provoking discussion on software development, supply chain security, and the innovative initiatives of the Silicon Valley Innovation Program (SVIP). The conversation was led by host Sean Martin, with insights from distinguished guests Melissa Oh, Managing Director at the Department of Homeland Security Science and Technology Directorate, and Anil John, Technical Director of the Silicon Valley Innovation Program.Melissa Oh shared her extensive experience in public service and the innovative approach of the Silicon Valley Innovation Program in identifying emerging technology companies. Her background in Silicon Valley and dedication to solving DHS's pain points through collaboration with startups underscored the program's mission of fostering innovation in the government sector.Anil John, a public interest technologist, provided valuable insights into bridging the gap between the government and the startup community. His role in translating government needs into actionable solutions highlighted the importance of leveraging global talent to address local challenges and drive technological advancements in the public sector.The discussion explored the Silicon Valley Innovation Program's unique selection process for startups, focusing on building products that have broad utility and can be readily adopted. The success story of the protobom project transitioning into an open-source tool exemplified the program's commitment to nurturing innovative solutions with real-world applications.The significance of Software Bill of Materials (SBOM) in enhancing software supply chain visibility was emphasized, with a call to action for organizations to prioritize its inclusion in software development processes. By driving awareness and adoption of SBOM, the SVIP is empowering security leaders to enhance software security and visualization in the development pipeline.Security leaders were encouraged to explore tools and technologies that enhance software security and visualization in the development pipeline. A call to action was made to participate in the SVIP demo week to learn about innovative solutions and capabilities and to drive the adoption of SBOM within organizations.Key Questions AddressedHow does the Silicon Valley Innovation Program (SVIP) bridge the gap between government needs and startup innovations in cybersecurity?What role does the Software Bill of Materials (SBOM) play in enhancing software supply chain security?How can organizations, both public and private, benefit from the innovative solutions developed through the SVIP for software supply chain visibility?___________________________Watch this and other videos on ITSPmagazine's YouTube ChannelRedefining CyberSecurity Podcast with Sean Martin, CISSP playlist:

Guests: Melissa Oh, Managing Director, Silicon Valley Innovation Program (SVIP), DHS Science & Technology Directorate [@DHSgov]On LinkedIn | https://www.linkedin.com/in/melissa-oh/Anil John, Technical Director, Silicon Valley Innovation Program (SVIP), DHS Science & Technology Directorate [@DHSgov]On LinkedIn | https://www.linkedin.com/in/aniljohn/On Twitter | https://twitter.com/aniltj____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinView This Show's Sponsors___________________________Episode NotesThis new episode of the 'Redefining Cybersecurity' podcast features a thought-provoking discussion on software development, supply chain security, and the innovative initiatives of the Silicon Valley Innovation Program (SVIP). The conversation was led by host Sean Martin, with insights from distinguished guests Melissa Oh, Managing Director at the Department of Homeland Security Science and Technology Directorate, and Anil John, Technical Director of the Silicon Valley Innovation Program.Melissa Oh shared her extensive experience in public service and the innovative approach of the Silicon Valley Innovation Program in identifying emerging technology companies. Her background in Silicon Valley and dedication to solving DHS's pain points through collaboration with startups underscored the program's mission of fostering innovation in the government sector.Anil John, a public interest technologist, provided valuable insights into bridging the gap between the government and the startup community. His role in translating government needs into actionable solutions highlighted the importance of leveraging global talent to address local challenges and drive technological advancements in the public sector.The discussion explored the Silicon Valley Innovation Program's unique selection process for startups, focusing on building products that have broad utility and can be readily adopted. The success story of the protobom project transitioning into an open-source tool exemplified the program's commitment to nurturing innovative solutions with real-world applications.The significance of Software Bill of Materials (SBOM) in enhancing software supply chain visibility was emphasized, with a call to action for organizations to prioritize its inclusion in software development processes. By driving awareness and adoption of SBOM, the SVIP is empowering security leaders to enhance software security and visualization in the development pipeline.Security leaders were encouraged to explore tools and technologies that enhance software security and visualization in the development pipeline. A call to action was made to participate in the SVIP demo week to learn about innovative solutions and capabilities and to drive the adoption of SBOM within organizations.Key Questions AddressedHow does the Silicon Valley Innovation Program (SVIP) bridge the gap between government needs and startup innovations in cybersecurity?What role does the Software Bill of Materials (SBOM) play in enhancing software supply chain security?How can organizations, both public and private, benefit from the innovative solutions developed through the SVIP for software supply chain visibility?___________________________Watch this and other videos on ITSPmagazine's YouTube ChannelRedefining CyberSecurity Podcast with Sean Martin, CISSP playlist:

Everyone knows that Software bills of material (SBOMS) are crucial to cybersecurity. But deciphering these documents has been a challenge for many agencies. The Silicon Valley Innovation Program aims to help. It is part of the Homeland Security Science and Technology Directorate. It has a program to promote development of what it calls "supply chain visibility tools." For details, Federal Drive Host Tom Temin spoke with the managing director of the Silicon Valley Innovation Program, Melissa Oh and with it technical director, Anil John. Learn more about your ad choices. Visit megaphone.fm/adchoices

In this episode of ADCG's Privacy and Cybersecurity Podcast, Jody Westby interviews Jean Camp, Director of the Center for Security and Privacy in Informatics, Computing, and Engineering and Professor of Informatics at University of Indiana. Prof. Camp is a renowned thought leader in privacy and cybersecurity and has conducted meaningful research on issues related to SBOMs and how they could be more effective. In this podcast, we explore the role of SBOMs in cybersecurity, what limits their effectiveness, and the Federal Government's role in advancing the use of SBOMs, developing tools to ease the use of SBOMs, and international efforts to create a harmonized approach to the development and use of SBOMs. Links to some of Prof. Camp's work in this area is available on the ADCG website.

Podcast: HouSecCastEpisode: Community Building with Roya GordonPub date: 2024-04-03Co-Host Sam Van Ryder flies solo for this episode with Executive Industry Consultant, Roya Gordon! They share insights on SBOMs and their significance in OT security, discuss what current security conferences are doing right (and where they could improve!), and the importance of building local cybersecurity communities. Things Mentioned:·      Southern Company Builds SBOM for Electric Power Substation - https://www.darkreading.com/ics-ot-security/southern-company-builds-a-power-substation-sbom?mc_cid=4ef3664287&mc_eid=UNIQIDDo you have a question for the hosts? Reach out to us at podcast@houstonseccon.com Keep up with HOU.SEC.CON:·      LinkedIn·      Twitter·      Facebook·      Instagram·      YouTube Check out our other show:·      CyberSundayCheck out our Conferences and Events:·      HOU.SEC.CON.·      OT.SEC.CON.·      EXEC.SEC.CON.·      HSC User GroupSupport or apply to our Scholarship Program:·      TAB Cyber FoundationIn this episode:·      Host: Michael Farnum·      Host: Sam Van Ryder·      Guest: Roya Gordon·      Editing by: Lauren Lynch·      Music by: August HoneyThe podcast and artwork embedded on this page are from Michael Farnum and Sam Van Ryder, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

Podcast: HOU.SEC.CAST.Episode: Community Building with Roya GordonPub date: 2024-04-03Co-Host Sam Van Ryder flies solo for this episode with Executive Industry Consultant, Roya Gordon! They share insights on SBOMs and their significance in OT security, discuss what current security conferences are doing right (and where they could improve!), and the importance of building local cybersecurity communities. Things Mentioned:·      Southern Company Builds SBOM for Electric Power Substation - https://www.darkreading.com/ics-ot-security/southern-company-builds-a-power-substation-sbom?mc_cid=4ef3664287&mc_eid=UNIQIDDo you have a question for the hosts? Reach out to us at podcast@houstonseccon.com Keep up with HOU.SEC.CON:·      LinkedIn·      Twitter·      Facebook·      Instagram·      YouTube Check out our other show:·      CyberSundayCheck out our Conferences and Events:·      HOU.SEC.CON.·      OT.SEC.CON.·      EXEC.SEC.CON.·      HSC User GroupSupport or apply to our Scholarship Program:·      TAB Cyber FoundationIn this episode:·      Host: Michael Farnum·      Host: Sam Van Ryder·      Guest: Roya Gordon·      Editing by: Lauren Lynch·      Music by: August HoneyThe podcast and artwork embedded on this page are from Michael Farnum and Sam Van Ryder, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

With the increasing complexity of software systems, the use of third-party components has become a widespread practice. Cyber disruptions, such as SolarWinds and Log4j, demonstrate the harm that can occur when organizations fail to manage third-party components in their software systems. In this podcast from the Carnegie Mellon University Software Engineering Institute, Carol Woody, principal researcher, and Michael Bandor, a senior software engineer, discuss a Software Bill of Materials (SBOMs) framework to help promote the use of SBOMs and establish a more comprehensive set of practices and processes that organizations can leverage as they build their programs. They also offer guidance for government agencies who are interested in incorporating SBOMs into their work. 

Tracy Ragan⁠ discusses software supply chain management and the importance of generating and consuming Software Bill of Materials (SBOMs) in decoupled architectures. She explains the challenges of managing libraries and dependencies in microservices and the need for aggregated SBOMs. Tracy emphasizes the importance of rapid response to vulnerabilities and the value of SBOMs in facilitating this response. She also discusses the requirements and industries for SBOMs and the role of SBOMs in analyzing and securing open source and commercial software. Tracy introduces ⁠DeployHub⁠ as a DevSecOps evidence store that helps teams gain confidence in the use and consumption of open source software and enables rapid response to vulnerabilities. Takeaways Software supply chain management involves generating and consuming SBOMs to track libraries and dependencies in decoupled architectures. In decoupled architectures, it is important to generate SBOMs for each microservice and aggregate them to understand the overall software supply chain. SBOMs should be generated for every build and provide visibility into the vulnerabilities and dependencies of each component. The quality of SBOMs is determined by their ability to facilitate rapid response to vulnerabilities and enable collaboration among teams. While SBOMs are not currently required in all industries, their importance is increasing, especially in sectors like government and fintech. Understanding the impact of vulnerabilities is crucial for effective response and prioritization. Rapid response to vulnerabilities is essential to minimize the potential impact on production environments. Centralized data and information are necessary for effective vulnerability management. Fixing vulnerabilities in open source software can be challenging due to the lack of accountability and maintenance. Controlling open source consumption and managing the software supply chain are complex tasks. DeployHub provides a DevSecOps evidence store that helps teams gain confidence in the use of open source software and enables rapid response to vulnerabilities. Chapters 00:00 Introduction to Software Supply Chain Management 03:22 Understanding Architecture in the Context of SBOMs 06:12 Configuration Management in Monolithic Applications 07:39 Challenges of Decoupled Architecture in Microservices 09:20 The Need for SBOMs in Decoupled Architectures 11:15 Generating Aggregated SBOMs for Microservices 13:24 Generating SBOMs for Each Microservice 15:23 Generating SBOMs for Every Build 17:15 Managing Libraries and Dependencies in Decoupled Architectures 19:31 The Importance of Consuming SBOM Data 22:30 Generating SBOMs with Tools 24:28 The Format and Consumption of SBOMs 27:55 The Importance of Consuming and Analyzing SBOM Data 29:43 Requirements and Industries for SBOMs 33:29 SBOMs for Open Source and Commercial Software 36:01 The Role of SBOMs in Rapidly Responding to Vulnerabilities 39:05 The Value of SBOMs in Rapid Response Systems 43:13 Defining the Quality of SBOMs 44:06 Understanding the Impact of Vulnerabilities 46:03 The Importance of Rapid Response 48:35 The Need for Centralized Data and Information 50:27 Challenges in Fixing Vulnerabilities 52:14 The Accountability of Open Source Software 53:41 The Difficulty of Controlling Open Source Consumption 55:16 Introduction to DeployHub 57:43 Managing the Software Supply Chain Tracy Ragan's Links: ⁠Linkedln Profile⁠ ⁠⁠DeployHub⁠⁠ Snowpal Products Backends as Services on ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠AWS Marketplace⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Mobile Apps on ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠App Store⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Play Store⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Web App⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Education Platform⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ for Learners and Course Creators

Guests Karthik Ram | James Howison Panelist Richard Littauer Show Notes In this captivating episode of Sustain, host Richard welcomes returning guest, Karthik Ram, Senior Research Scientist at the Berkeley Institute for Data Science, and his colleague James Howison, an Associate Professor from the School of Information at the University of Texas, Austin. Today, they delve into their recent research report, “‘Research Software Visibility Infrastructure Priorities,” commissioned for the Australian Research Data Commons. They discuss their eight key recommendations about sustaining open source for the long haul, including ways to recognize software contribution, implement web analytics, and offer low friction ways for researchers to link software. Karthik and James also touch on the future of software citations in academic recognition systems, and the importance of universities valuing diverse academic outputs. Don't miss this fascinating conversation! Press download now! [00:01:36] Richard brings up a paper written by Karthik and James. Karthik explains the report titled, “Research Software Visibility Infrastructure Priorities,” produced for the Australian Research Data Commons (ARDC). He describes the process of creating the report and the report's relevance beyond Australia. [00:06:24] Richard asks how this is related to open source, and James relates the recommendations, focusing on citing software in publications and creating software bill of materials for research papers. [00:08:02] James and Karthik discuss recommendations, focusing on citing software in publications and creating software bill of materials for research papers. [00:12:02] Richard endorses the use of SBOMs for citing all software used in research, aiming to counter the issue of only popular projects getting noticed, but he questions how SBOMs account for the varying importance of different software dependencies. Karthik clarifies the SBOMs are not meant to create equal value citations for all software but to understand the scientific infrastructure that supports research. [00:15:28] Richard suggests that SBOMs could be useful in industrial contexts for security purposes and infrastructure visibility. Karthik agrees, stating that SBOMs have a broader application and were originally created for security reasons to track vulnerabilities. [00:17:41] James introduces the third recommendation to create software use infrascope as an observatory based on software mentions publications. He discusses the challenge of identifying software mentions in publications and the work done towards building comprehensive view of software in academia. [00:22:34] Karthik introduces the fourth recommendation to create detailed use cases for research tools aimed at different skill levels, addressing the challenge researchers face when selecting software tools. [00:24:29] Richard highlights the necessity of allocating time in research planning for writing documentation and tutorials, which James agrees is crucial for making software tools more accessible to researchers. [00:26:30] James discusses the fifth recommendation, which is to support existing technology for software archiving, such as Zenodo or Software Heritage, rather than creating new repositories at the institutional level. [00:28:28] Karthik talks about sixth recommendation and supporting communities of practice like hackathons and other collaborative spaces, which have shown to have a positive impact on research productivity. James describes the need for third spaces that are neither too local nor too public. Where researchers can comfortably ask questions and share insights within a focused community. [00:31:08] James introduces the seventh recommendation which is about implementing web analytics to gain insights into software usage, as citations alone do not reflect the full impact of research software. [00:33:48] James acknowledges the need for infrastructure to enhance insight from SBOMs and mentions the necessity of funding to maintain services that provide such data. [00:35:53] Richard highlights the eighth recommendation, which suggests providing an easy way for researchers to link to software alongside data submissions. James directs listeners to the Softcite GitHub organization and mentions the upcoming blog post about their report on the URSSI Blog. [00:36:16] Karthik and James tell us where you can find out more about their work and find them on the web. Quotes [00:08:40] “Absolutely every piece of software that you use in your whole stack should be cited, but I've had some issues with that in publications.” [00:09:04] “What we identified was that different fields have different norms for what rises to the level of contribution for actually being mentioned formally in the publication.” [00:14:40] “The researchers are experts in scientific explanation and they're going to pick packages to mention that pertain to understanding the research that's done in the paper, whereas the SBOM is going to give us insight into the software infrastructure that made the research possible.” Spotlight [00:38:26] Richard's spotlight is iNaturalist. [00:39:00] Karthik's spotlight is Kyle Niemeyer at Oregon State. [00:39:34] James's spotlight is Eva Brown and her Council Data Project. Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Mastodon (https://mastodon.social/@richlitt) Karthik Ram Website (https://ram.berkeley.edu/) Karthik Ram LinkedIn (https://www.linkedin.com/in/karthik-ram-93334954/) Karthik Ram X/Twitter (https://twitter.com/_inundata) James Howison X/Twitter (https://twitter.com/jameshowison) James Howison-University of Texas, Austin (https://www.ischool.utexas.edu/people/people-details?PersonID=175) Research Software Visibility Infrastructure Priorities Report by Dr. Karthik Ram and Dr. James Howison (Zenodo) (https://zenodo.org/records/10060255) Sustain Podcast-2 Episodes featuring Daniel Stenburg (https://podcast.sustainoss.org/guests/stenberg) Sustain Podcast-Episode 187: Karthik Ram on Research Software Sustainability (https://podcast.sustainoss.org/guests/ram) Depsy (http://depsy.org/) Softcite dataset (https://github.com/howisonlab/softcite-dataset) Softcite software mention recognition service (https://github.com/softcite/software-mentions) Softcite-GitHub (https://github.com/softcite/) SoMeSci-Software Mentions in Science (https://data.gesis.org/somesci/) Mapping the Impact of Research Software in Science (https://github.com/chanzuckerberg/software-impact-hackathon-2023) The Scientific Community Image Forum (Frequently Asked Questions) (https://forum.image.sc/t/frequently-asked-questions/18729) HackyHour (https://hackyhour.github.io/) Sustain Podcast-Episode 95: Marko Saric of Plausible Analytics, the most popular Open Source analytics platform (https://podcast.sustainoss.org/95) URSSI Blog (https://urssi.us/blog/) Ecosyste.ms (https://ecosyste.ms/) Incentives and integration in scientific software production by James Howison and James D. Herbsleb (https://dl.acm.org/doi/10.1145/2441776.2441828) Python Package Citation Generator-GitHub (https://github.com/RichardLitt/dependency-cite) iNaturalist (https://www.inaturalist.org/) Kyle Niemeyer (https://engineering.oregonstate.edu/people/kyle-niemeyer) Eva Brown GitHub (https://evamaxfield.github.io/) Council Data Project (https://councildataproject.org/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guests: James Howison and Karthik Ram.

Matt Lewis from the NCC Group joins to discuss how cybercriminals can decode your personality through AI conversations to launch targeted attacks at you. Dave and Joe share some follow up from listener Sydney, who writes in to share her thoughts on an FCC proceeding and how it could be of greater relevance to IoT security than SBOMs and HBOMs. Dave also shares a story from a listener from last Christmas, sending a warning to holiday shoppers. Dave has two stories this week, he shares one regarding an announcement on holiday scams coming out. His other story follows Zelle finally caving in to provide some relief to scam victims. Joe's story follows new crypto-theft attacks and warns people against the new tactics. Links to the stories: 2023 Holiday Shopping Scams Zelle finally caves after years of refusing to refund scam victims Microsoft: BlueNoroff hackers plan new crypto-theft attacks Have a Catch of the Day you'd like to share? Email it to us at hackinghumans@thecyberwire.com.

A US mortgage company reveals major data breach. Updates from CISA. NSA provides guidance on SBOMs. MongoDB warns customers of a breach. BlackCat/ALPHV is still a market leader, but feeling competitive pressure. Reassessing the effects of Log4shell. The International Committee of the Red Cross calls for restraint in cyber warfare. Ransomware hits a cancer center. Ann Johnson, host of Microsoft Security's Afternoon Cyber Tea podcast goes beyond basics with her guest Tanya Janca, founder of WeHackPurple. And what can I do to make you take home this chatbot today? Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Host of Microsoft Security's Afternoon Cyber Tea podcast, Ann Johnson, goes beyond basics with her guest Tanya Janca, founder of WeHackPurple. Ann's full discussion with Tanya can be heard here. You can catch Afternoon Cyber Tea every other Tuesday on your favorite podcast apps and the N2K Network.  Selected Reading Mr. Cooper reveals breach exposed 14.6 million clients (Cybernews) Enhancing Cyber Resilience: Insights from the CISA Healthcare and Public Health Sector Risk and Vulnerability Assessment (CISA) NSA Issues Guidance on Incorporating SBOMs to Improve Cybersecurity (Security Week) MongoDB says customer data was exposed in a cyberattack (Bleeping Computer) ALPHV Targeting: Ransomware & Digital Extortion (ZeroFox) A Log4Shell Retrospective - Overblown and Exaggerated (VulnCheck) We call on States to stop turning a blind eye to the participation of civilian hackers in armed conflict (ICRC) Seattle cancer center confirms cyberattack after ransomware gang threats (The Record) What can I do to make you take home this chatbot today? (Mastodon) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © 2023 N2K Networks, Inc.

Simply knowing what is in your software is not any guarantee of safety. We need to know what that software does versus what we expect it to do. We need to know its rules of behavior.  Today, we talk with Andrew Hendela, a founder of Karambit.ai, a company dedicated to automatically detecting malware and securing your software supply chain. Andrew worked for over a decade automating hard cybersecurity problems. He has many years of experience in cybersecurity leadership and deep technical expertise in fields such as malware analysis and automated cyber attribution. He tells us about software bills of behavior and why SBOMs are insufficient to protect your software supply chain from attacks.  When you finish listening to the episode, connect with Andrew on LinkedIn and visit Karambit.ai website.  Mentioned in this episode: Andrew on LinkedIn at https://www.linkedin.com/in/andrew-hendela/ Karambit.ai at https://karambit.ai 

What will the future bring with respect to AI and LLMs? Josh has spent some time thinking about this and brings us some great resources. We'll discuss how to get students involved with AI in a safe and ethical manner. How can we use AI to teach people about cybersecurity? What tools are available and where do they fit into our educational systems that must change and adapt to the times? Join us for a fun discussion on what the future looks like with AI and the youth of today. Segment Resources: https://docs.google.com/document/d/103FLvNRSwBhq-WgCbuykMvweT6lKf2lAASuP8OuuKIw/edit#heading=h.3inodmot2b77 Our good friend Matt Carpenter joins us to share his thoughts on what's going on in the world of AI and LLMs. Matt is also a hacker specializing in hardware and the crew has some amazing hardware hacking topics to discuss (as usual). Segment Resources: https://garymarcus.substack.com/p/has-sam-altman-gone-full-gary-marcus We navigate through dangerous cyber terrain, examining real-world examples like the WebP library and the Curl vulnerability. Critical issues in Zyxel firewalls will also be unmasked as we shed light on the urgency of improving vulnerability reporting and cataloging and addressing the often-overlooked problem of overclassifying harmless software bugs. We then shifted gears to tackle the tricky subject of software vulnerability identification, focusing on a specific CVE that sparked intriguing debates. Learn why pinpointing the source of the vulnerability is vital to effective SBOMs. The journey doesn't end there - we'll uncover a newly discovered Bluetooth vulnerability, aptly named 'BLUFFS', and discuss its potential for exploitation, along with the ingenious solutions proposed by the researchers who unearthed it. Brace yourself for a riveting finale as we delve into Akamai's recent research on DVR and router attacks, explore the risks of GPS spoofing, and discuss the importance of detection mechanisms. We'll also scrutinize the stereotype of hackers in pop culture, address the importance of handling vulnerabilities in software, and highlight the pressing issue of ransomware targeting healthcare. So buckle up and join us for this critical exploration into the world of software vulnerabilities as we decode the complexities and debunk some security myths. Visit https://www.securityweekly.com/psw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly Visit https://www.securityweekly.com/psw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/psw-808

Episode sponsors: Binarly (https://binarly.io) FwHunt (https://fwhunt.run) Dan Lorenc is CEO and co-founder of Chainguard, a company that raised $116 million in less than two years to tackle open source supply chain security problems. In this episode, Dan joins Ryan to chat about the demands of building a "growth mode" startup, massive funding rounds and VC expectations, fixing the "crappy" CVE and CVSS ecosystems, managing expectations around SBOMs, and how politicians and lobbyists are framing cybersecurity issues in strange ways.

Adnan Khan, Lead Security Engineer at Praetorian, joins Corey on Screaming in the Cloud to discuss software bill of materials and supply chain attacks. Adnan describes how simple pull requests can lead to major security breaches, and how to best avoid those vulnerabilities. Adnan and Corey also discuss the rapid innovation at Github Actions, and the pros and cons of having new features added so quickly when it comes to security. Adnan also discusses his view on the state of AI and its impact on cloud security. About AdnanAdnan is a Lead Security Engineer at Praetorian. He is responsible for executing on Red-Team Engagements as well as developing novel attack tooling in order to meet and exceed engagement objectives and provide maximum value for clients.His past experience as a software engineer gives him a deep understanding of where developers are likely to make mistakes, and has applied this knowledge to become an expert in attacks on organization's CI/CD systems.Links Referenced: Praetorian: https://www.praetorian.com/ Twitter: https://twitter.com/adnanthekhan Praetorian blog posts: https://www.praetorian.com/author/adnan-khan/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Are you navigating the complex web of API management, microservices, and Kubernetes in your organization? Solo.io is here to be your guide to connectivity in the cloud-native universe!Solo.io, the powerhouse behind Istio, is revolutionizing cloud-native application networking. They brought you Gloo Gateway, the lightweight and ultra-fast gateway built for modern API management, and Gloo Mesh Core, a necessary step to secure, support, and operate your Istio environment.Why struggle with the nuts and bolts of infrastructure when you can focus on what truly matters - your application. Solo.io's got your back with networking for applications, not infrastructure. Embrace zero trust security, GitOps automation, and seamless multi-cloud networking, all with Solo.io.And here's the real game-changer: a common interface for every connection, in every direction, all with one API. It's the future of connectivity, and it's called Gloo by Solo.io.DevOps and Platform Engineers, your journey to a seamless cloud-native experience starts here. Visit solo.io/screaminginthecloud today and level up your networking game.Corey: As hybrid cloud computing becomes more pervasive, IT organizations need an automation platform that spans networks, clouds, and services—while helping deliver on key business objectives. Red Hat Ansible Automation Platform provides smart, scalable, sharable automation that can take you from zero to automation in minutes. Find it in the AWS Marketplace.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I've been studiously ignoring a number of buzzword, hype-y topics, and it's probably time that I addressed some of them. One that I've been largely ignoring, mostly because of its prevalence at Expo Hall booths at RSA and other places, has been software bill of materials and supply chain attacks. Finally, I figured I would indulge the topic. Today I'm speaking with Adnan Khan, lead security engineer at Praetorian. Adnan, thank you for joining me.Adnan: Thank you so much for having me.Corey: So, I'm trying to understand, on some level, where the idea of these SBOM or bill-of-material attacks have—where they start and where they stop. I've seen it as far as upstream dependencies have a vulnerability. Great. I've seen misconfigurations in how companies wind up configuring their open-source presences. There have been a bunch of different, it feels almost like orthogonal concepts to my mind, lumped together as this is a big scary thing because if we have a big single scary thing we can point at, that unlocks budget. Am I being overly cynical on this or is there more to it?Adnan: I'd say there's a lot more to it. And there's a couple of components here. So first, you have the SBOM-type approach to security where organizations are looking at which packages are incorporated into their builds. And vulnerabilities can come out in a number of ways. So, you could have software actually have bugs or you could have malicious actors actually insert backdoors into software.I want to talk more about that second point. How do malicious actors actually insert backdoors? Sometimes it's compromising a developer. Sometimes it's compromising credentials to push packages to a repository, but other times, it could be as simple as just making a pull request on GitHub. And that's somewhere where I've spent a bit of time doing research, building off of techniques that other people have documented, and also trying out some attacks for myself against two Microsoft repositories and several others that have reported over the last few months that would have been able to allow an attacker to slip a backdoor into code and expand the number of projects that they are able to attack beyond that.Corey: I think one of the areas that we've seen a lot of this coming from has been the GitHub Action space. And I'll confess that I wasn't aware of a few edge-case behaviors around this. Most of my experience with client-side Git configuration in the .git repository—pre-commit hooks being a great example—intentionally and by design from a security perspective, do not convey when you check that code in and push it somewhere, or grab someone else's, which is probably for the best because otherwise, it's, “Oh yeah, just go ahead and copy your password hash file and email that to something else via a series of arcane shell script stuff.” The vector is there. I was unpleasantly surprised somewhat recently to discover that when I cloned a public project and started running it locally and then adding it to my own fork, that it would attempt to invoke a whole bunch of GitHub Actions flows that I'd never, you know, allowed it to do. That was… let's say, eye-opening.Adnan: [laugh]. Yeah. So, on the particular topic of GitHub Actions, the pull request as an attack vector, like, there's a lot of different forms that an attack can take. So, one of the more common ones—and this is something that's been around for just about as long as GitHub Actions has been around—and this is a certain trigger called ‘pull request target.' What this means is that when someone makes a pull request against the base repository, maybe a branch within the base repository such as main, that will be the workflow trigger.And from a security's perspective, when it runs on that trigger, it does not require approval at all. And that's something that a lot of people don't really realize when they're configuring their workflows. Because normally, when you have a pull request trigger, the maintainer can check a box that says, “Oh, require approval for all external pull requests.” And they think, “Great, everything needs to be approved.” If someone tries to add malicious code to run that's on the pull request target trigger, then they can look at the code before it runs and they're fine.But in a pull request target trigger, there is no approval and there's no way to require an approval, except for configuring the workflow securely. So, in this case, what happens is, and in one particular case against the Microsoft repository, this was a Microsoft reusable GitHub Action called GPT Review. It was vulnerable because it checked out code from my branch—so if I made a pull request, it checked out code from my branch, and you could find this by looking at the workflow—and then it ran tests on my branch, so it's running my code. So, by modifying the entry points, I could run code that runs in the context of that base branch and steal secrets from it, and use those to perform malicious Actions.Corey: Got you. It feels like historically, one of the big threat models around things like this is al—[and when 00:06:02] you have any sort of CI/CD exploit—is either falls down one of two branches: it's either the getting secret access so you can leverage those credentials to pivot into other things—I've seen a lot of that in the AWS space—or more boringly, and more commonly in many cases, it seems to be oh, how do I get it to run this crypto miner nonsense thing, with the somewhat large-scale collapse of crypto across the board, it's been convenient to see that be less prevalent, but still there. Just because you're not making as much money means that you'll still just have to do more of it when it's all in someone else's account. So, I guess it's easier to see and detect a lot of the exploits that require a whole bunch of compute power. The, oh by the way, we stole your secrets and now we're going to use that to lateral into an organization seem like it's something far more… I guess, dangerous and also sneaky.Adnan: Yeah, absolutely. And you hit the nail on the head there with sneaky because when I first demonstrated this, I made a test account, I created a PR, I made a couple of Actions such as I modified the name of the release for the repository, I just put a little tag on it, and didn't do any other changes. And then I also created a feature branch in one of Microsoft's repositories. I don't have permission to do that. That just sat there for about almost two weeks and then someone else exploited it and then they responded to it.So, sneaky is exactly the word you could describe something like this. And another reason why it's concerning is, beyond the secret disclosure for—and in this case, the repository only had an OpenAI API key, so… okay, you can talk to ChatGPT for free. But this was itself a Github Action and it was used by another Microsoft machine-learning project that had a lot more users, called SynapseML, I believe was the name of the other project. So, what someone could do is backdoor this Action by creating a commit in a feature branch, which they can do by stealing the built-in GitHub token—and this is something that all Github Action runs have; the permissions for it vary, but in this case, it had the right permissions—attacker could create a new branch, modify code in that branch, and then modify the tag, which in Git, tags are mutable, so you can just change the commit the tag points to, and now, every time that other Microsoft repository runs GPT Review to review a pull request, it's running attacker-controlled code, and then that could potentially backdoor that other repository, steal secrets from that repository.So that's, you know, one of the scary parts of, in particular backdooring a Github Action. And I believe there was a very informative Blackhat talk this year, that someone from—I'm forgetting the name of the author, but it was a very good watch about how Actions vulnerabilities can be vulnerable, and this is kind of an example of—it just happened to be that this was an Action as well.Corey: That feels like this is an area of exploit that is becoming increasingly common. I tie it almost directly to the rise of GitHub Actions as the default CI/CD system that a lot of folks have been using. For the longest time, it seemed like a poorly configured Jenkins box hanging out somewhere in your environment that was the exception to the Infrastructure as Code rule because everyone has access to it, configures it by hand, and invariably it has access to production was the way that people would exploit things. For a while, you had CircleCI and Travis-CI, before Travis imploded and Circle did a bunch of layoffs. Who knows where they're at these days?But it does seem that the common point now has been GitHub Actions, and a .github folder within that Git repo with a workflows YAML file effectively means that a whole bunch of stuff can happen that you might not be fully aware of when you're cloning or following along with someone's tutorial somewhere. That has caught me out in a couple of strange ways, but nothing disastrous because I do believe in realistic security boundaries. I just worry how much of this is the emerging factor of having a de facto standard around this versus something that Microsoft has actively gotten wrong. What's your take on it?Adnan: Yeah. So, my take here is that Github could absolutely be doing a lot more to help prevent users from shooting themselves in the foot. Because their documentation is very clear and quite frankly, very good, but people aren't warned when they make certain configuration settings in their workflows. I mean, GitHub will happily take the settings and, you know, they hit commit, and now the workflow could be vulnerable. There's no automatic linting of workflows, or a little suggestion box popping up like, “Hey, are you sure you want to configure it this way?”The technology to detect that is there. There's a lot of third-party utilities that will lint Actions workflows. Heck, for looking for a lot of these pull request target-type vulnerabilities, I use a Github code search query. It's just a regular expression. So, having something that at least nudges users to not make that mistake would go really far in helping people not make these mista—you know, adding vulnerabilities to their projects.Corey: It seems like there's also been issues around the GitHub Actions integration approach where OICD has not been scoped correctly a bunch of times. I've seen a number of articles come across my desk in that context and fortunately, when I wound up passing out the ability for one of my workflows to deploy to my AWS account, I got it right because I had no idea what I was doing and carefully followed the instructions. But I can totally see overlooking that one additional parameter that leaves things just wide open for disaster.Adnan: Yeah, absolutely. That's one where I haven't spent too much time actually looking for that myself, but I've definitely read those articles that you mentioned, and yeah, it's very easy for someone to make that mistake, just like, it's easy for someone to just misconfigure their Action in general. Because in some of the cases where I found vulnerabilities, there would actually be a commit saying, “Hey, I'm making this change because the Action needs access to these certain secrets. And oh, by the way, I need to update the checkout steps so it actually checks out the PR head so that it's [testing 00:12:14] that PR code.” Like, people are actively making a decision to make it vulnerable because they don't realize the implication of what they've just done.And in the second Microsoft repository that I found the bug in, was called Microsoft Confidential Sidecar Containers. That repository, the developer a week prior to me identifying the bug made a commit saying that we're making a change and it's okay because it requires approval. Well, it doesn't because it's a pull request target.Corey: Part of me wonders how much of this is endemic to open-source as envisioned through enterprises versus my world of open-source, which is just eh, I've got this weird side project in my spare time, and it seemed like it might be useful to someone else, so I'll go ahead and throw it up there. I understand that there's been an awful lot of commercialization of open-source in recent years; I'm not blind to that fact, but it also seems like there's a lot of companies playing very fast and loose with things that they probably shouldn't be since they, you know, have more of a security apparatus than any random contributors standing up a clone of something somewhere will.Adnan: Yeah, we're definitely seeing this a lot in the machine-learning space because of companies that are trying to move so quickly with trying to build things because OpenAI AI has blown up quite a bit recently, everyone's trying to get a piece of that machine learning pie, so to speak. And another thing of what you're seeing is, people are deploying self-hosted runners with Nvidia, what is it, the A100, or—it's some graphics card that's, like, $40,000 apiece attached to runners for running integration tests on machine-learning workflows. And someone could, via a pull request, also just run code on those and mine crypto.Corey: I kind of miss the days when exploiting computers is basically just a way for people to prove how clever they were or once in a blue moon come up with something innovative. Now, it's like, well, we've gone all around the mulberry bush just so we can basically make computers solve a sudoku form, and in return, turn that into money down the road. It's frustrating, to put it gently.Adnan: [laugh].Corey: When you take a look across the board at what companies are doing and how they're embracing the emerging capabilities inherent to these technologies, how do you avoid becoming a cautionary tale in the space?Adnan: So, on the flip side of companies having vulnerable workflows, I've also seen a lot of very elegant ways of writing secure workflows. And some of the repositories are using deployment environments—which is the GitHub Actions feature—to enforce approval checks. So, workflows that do need to run on pull request target because of the need to access secrets for pull requests will have a step that requires a deployment environment to complete, and that deployment environment is just an approval and it doesn't do anything. So essentially, someone who has permissions to the repository will go in, approve that environment check, and only then will the workflow continue. So, that adds mandatory approvals to pull requests where otherwise they would just run without approval.And this is on, particularly, the pull request target trigger. Another approach is making it so the trigger is only running on the label event and then having a maintainer add a label so the tests can run and then remove the label. So, that's another approach where companies are figuring out ways to write secure workflows and not leave their repositories vulnerable.Corey: It feels like every time I turn around, Github Actions has gotten more capable. And I'm not trying to disparage the product; it's kind of the idea of what we want. But it also means that there's certainly not an awareness in the larger community of how these things can go awry that has kept up with the pace of feature innovation. How do you balance this without becoming the Department of No?Adnan: [laugh]. Yeah, so it's a complex issue. I think GitHub has evolved a lot over the years. Actions, it's—despite some of the security issues that happen because people don't configure them properly—is a very powerful product. For a CI/CD system to work at the scale it does and allow so many repositories to work and integrate with everything else, it's really easy to use. So, it's definitely something you don't want to take away or have an organization move away from something like that because they are worried about the security risks.When you have features coming in so quickly, I think it's important to have a base, kind of like, a mandatory reading. Like, if you're a developer that writes and maintains an open-source software, go read through this document so you can understand the do's and don'ts instead of it being a patchwork where some people, they take a good security approach and write secure workflows and some people just kind of stumble through Stack Overflow, find what works, messes around with it until their deployment is working and their CI/CD is working and they get the green checkmark, and then they move on to their never-ending list of tasks that—because they're always working on a deadline.Corey: Reminds me of a project I saw a few years ago when it came out that Volkswagen had been lying to regulators. It was a framework someone built called ‘Volkswagen' that would detect if it was running inside of a CI/CD environment, and if so, it would automatically make all the tests pass. I have a certain affinity for projects like that. Another one was a tool that would intentionally degrade the performance of a network connection so you could simulate having a latent or stuttering connection with packet loss, and they call that ‘Comcast.' Same story. I just thought that it's fun seeing people get clever on things like that.Adnan: Yeah, absolutely.Corey: When you take a look now at the larger stories that are emerging in the space right now, I see an awful lot of discussion coming up that ties to SBOMs and understanding where all of the components of your software come from. But I chased some stuff down for fun once, and I gave up after 12 dependency leaps from just random open-source frameworks. I mean, I see the Dependabot problem that this causes as well, where whenever I put something on GitHub and then don't touch it for a couple of months—because that's how I roll—I come back and there's a whole bunch of terrifyingly critical updates that it's warning me about, but given the nature of how these things get used, it's never going to impact anything that I'm currently running. So, I've learned to tune it out and just ignore it when it comes in, which is probably the worst of all possible approaches. Now, if I worked at a bank, I should probably take a different perspective on this, but I don't.Adnan: Mm-hm. Yeah. And that's kind of a problem you see, not just with SBOMs. It's just security alerting in general, where anytime you have some sort of signal and people who are supposed to respond to it are getting too much of it, you just start to tune all of it out. It's like that human element that applies to so much in cybersecurity.And I think for the particular SBOM problem, where, yeah, you're correct, like, a lot of it… you don't have reachability because you're using a library for one particular function and that's it. And this is somewhere where I'm not that much of an expert in where doing more static source analysis and reachability testing, but I'm certain there are products and tools that offer that feature to actually prioritize SBOM-based alerts based on actual reachability versus just having an as a dependency or not.[midroll 00:20:00]Corey: I feel like, on some level, wanting people to be more cautious about what they're doing is almost shouting into the void because I'm one of the only folks I found that has made the assertion that oh yeah, companies don't actually care about security. Yes, they email you all the time after they failed to protect your security, telling you how much they care about security, but when you look at where they invest, feature velocity always seems to outpace investment in security approaches. And take a look right now at the hype we're seeing across the board when it comes to generative AI. People are excited about the capabilities and security is a distant afterthought around an awful lot of these things. I don't know how you drive a broader awareness of this in a way that sticks, but clearly, we haven't collectively found it yet.Adnan: Yeah, it's definitely a concern. When you see things on—like for example, you can look at Github's roadmap, and there's, like, a feature there that's, oh, automatic AI-based pull request handling. Okay, so does that mean one day, you'll have a GitHub-powered LLM just approve PRs based on whether it determines that it's a good improvement or not? Like, obviously, that's not something that's the case now, but looking forward to maybe five, six years in the future, in the pursuit of that ever-increasing velocity, could you ever have a situation where actual code contributions are reviewed fully by AI and then approved and merged? Like yeah, that's scary because now you have a threat actor that could potentially specifically tailor contributions to trick the AI into thinking they're great, but then it could turn around and be a backdoor that's being added to the code.Obviously, that's very far in the future and I'm sure a lot of things will happen before that, but it starts to make you wonder, like, if things are heading that way. Or will people realize that you need to look at security at every step of the way instead of just thinking that these newer AI systems can just handle everything?Corey: Let's pivot a little bit and talk about your day job. You're a lead security engineer at what I believe to be a security-focused consultancy. Or—Adnan: Yeah.Corey: If you're not a SaaS product. Everything seems to become a SaaS product in the fullness of time. What's your day job look like?Adnan: Yeah, so I'm a security engineer on Praetorian's red team. And my day-to-day, I'll kind of switch between application security and red-teaming. And that kind of gives me the opportunity to, kind of, test out newer things out in the field, but then also go and do more traditional application security assessments and code reviews, and reverse engineering to kind of break up the pace of work. Because red-teaming can be very fast and fast-paced and exciting, but sometimes, you know, that can lead to some pretty late nights. But that's just the nature of being on a red team [laugh].Corey: It feels like as soon as I get into the security space and start talking to cloud companies, they get a lot more defensive than when I'm making fun of, you know, bad service naming or APIs that don't make a whole lot of sense. It feels like companies have a certain sensitivity around the security space that applies to almost nothing else. Do you find, as a result, that a lot of the times when you're having conversations with companies and they figure out that, oh, you're a red team for a security researcher, oh, suddenly, we're not going to talk to you the way we otherwise might. We thought you were a customer, but nope, you can just go away now.Adnan: [laugh]. I personally haven't had that experience with cloud companies. I don't know if I've really tried to buy a lot. You know, I'm… if I ever buy some infrastructure from cloud companies as an individual, I just kind of sign up and put in my credit card. And, you know, they just, like, oh—you know, they just take my money. So, I don't really think I haven't really, personally run into anything like that yet [laugh].Corey: Yeah, I'm curious to know how that winds up playing out in some of these, I guess, more strategic, larger company environments. I don't get to see that because I'm basically a tiny company that dabbles in security whenever I stumble across something, but it's not my primary function. I just worry on some level one of these days, I'm going to wind up accidentally dropping a zero-day on Twitter or something like that, and suddenly, everyone's going to come after me with the knives. I feel like [laugh] at some point, it's just going to be a matter of time.Adnan: Yeah. I think when it comes to disclosing things and talking about techniques, the key thing here is that a lot of the things that I'm talking about, a lot of the things that I'll be talking about in some blog posts that have coming out, this is stuff that these companies are seeing themselves. Like, they recognize that these are security issues that people are introducing into code. They encourage people to not make these mistakes, but when it's buried in four links deep of documentation and developers are tight on time and aren't digging through their security documentation, they're just looking at what works, getting it to work and moving on, that's where the issue is. So, you know, from a perspective of raising awareness, I don't feel bad if I'm talking about something that the company itself agrees is a problem. It's just a lot of the times, their own engineers don't follow their own recommendations.Corey: Yeah, I have opinions on these things and unfortunately, it feels like I tend to learn them in some of the more unfortunate ways of, oh, yeah, I really shouldn't care about this thing, but I only learned what the norm is after I've already done something. This is, I think, the problem inherent to being small and independent the way that I tend to be. We don't have enough people here for there to be a dedicated red team and research environment, for example. Like, I tend to bleed over a little bit into a whole bunch of different things. We'll find out. So far, I've managed to avoid getting it too terribly wrong, but I'm sure it's just a matter of time.So, one area that I think seems to be a way that people try to avoid cloud issues is oh, I read about that in the last in-flight magazine that I had in front of me, and the cloud is super insecure, so we're going to get around all that by running our own infrastructure ourselves, from either a CI/CD perspective or something else. Does that work when it comes to this sort of problem?Adnan: Yeah, glad you asked about that. So, we've also seen open-s—companies that have large open-source presence on GitHub just opt to have self-hosted Github Actions runners, and that opens up a whole different Pandora's box of attacks that an attacker could take advantage of, and it's only there because they're using that kind of runner. So, the default GitHub Actions runner, it's just an agent that runs on a machine, it checks in with GitHub Actions, it pulls down builds, runs them, and then it waits for another build. So, these are—the default state is a non-ephemeral runner with the ability to fork off tasks that can run in the background. So, when you have a public repository that has a self-hosted runner attached to it, it could be at the organization level or it could be at the repository level.What an attacker can just do is create a pull request, modify the pull request to run on a self-hosted runner, write whatever they want in the pull request workflow, create a pull request, and now as long as they were a previous contributor, meaning you fixed a typo, you… that could be a such a, you know, a single character typo change could even cause that, or made a small contribution, now they create the pull request. The arbitrary job that they wrote is now picked up by that self-hosted runner. They can fork off it, process it to run in the background, and then that just continues to run, the job finishes, their pull request, they'll just—they close it. Business as usual, but now they've got an implant on the self-hosted runner. And if the runners are non-ephemeral, it's very hard to completely lock that down.And that's something that I've seen, there's quite a bit of that on GitHub where—and you can identify it just by looking at the run logs. And that's kind of comes from people saying, “Oh, let's just self-host our runners,” but they also don't configure that properly. And that opens them up to not only tampering with their repositories, stealing secrets, but now depending on where your runner is, now you potentially could be giving an attacker a foothold in your cloud environment.Corey: Yeah, that seems like it's generally a bad thing. I found that cloud tends to be more secure than running it yourself in almost every case, with the exception that once someone finds a way to break into it, there's suddenly a lot more eggs in a very large, albeit more secure, basket. So, it feels like it's a consistent trade-off. But as time goes on, it feels like it is less and less defensible, I think, to wind up picking out an on-prem strategy from a pure security point of view. I mean, there are reasons to do it. I'm just not sure.Adnan: Yeah. And I think that distinction to be made there, in particular with CI/CD runners is there's cloud, meaning you let your—there's, like, full cloud meaning you let your CI/CD provider host your infrastructure as well; there's kind of that hybrid approach you mentioned, where you're using a CI/CD provider, but then you're bringing your own cloud infrastructure that you think you could secure better; or you have your runners sitting in vCenter in your own data center. And all of those could end up being—both having a runner in your cloud and in your data center could be equally vulnerable if you're not segmenting builds properly. And that's the core issue that happens when you have a self-hosted runner is if they're not ephemeral, it's very hard to cut off all attack paths. There's always something an attacker can do to tamper with another build that'll have some kind of security impact. You need to just completely isolate your builds and that's essentially what you see in a lot of these newer guidances like the [unintelligible 00:30:04] framework, that's kind of the core recommendation of it is, like, one build, one clean runner.Corey: Yeah, that seems to be the common wisdom. I've been doing a lot of work with my own self-hosted runners that run inside of Lambda. Definitionally those are, of course, ephemeral. And there's a state machine that winds up handling that and screams bloody murder if there's a problem with it. So far, crossing fingers hoping it works out well.And I have a bounded to a very limited series of role permissions, and of course, its own account of constraint blast radius. But there's still—there are no guarantees in this. The reason I build it the way I do is that, all right, worst case someone can get access to this. The only thing they're going to have the ability to do is, frankly, run up my AWS bill, which is an area I have some small amount of experience with.Adnan: [laugh]. Yeah, yeah, that's always kind of the core thing where if you get into someone's cloud, like, well, just sit there and use their compute resources [laugh].Corey: Exactly. I kind of miss when that was the worst failure mode you had for these things.Adnan: [laugh].Corey: I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?Adnan: I do have a Twitter account. Well, I guess you can call it Twitter anymore, but, uh—Corey: Watch me. Sure I can.Adnan: [laugh]. Yeah, so I'm on Twitter, and it's @adnanthekhan. So, it's like my first name with ‘the' and then K-H-A-N because, you know, my full name probably got taken up, like, years before I ever made a Twitter account. So, occasionally I tweet about GitHub Actions there.And on Praetorian's website, I've got a couple of blog posts. I have one—the one that really goes in-depth talking about the two Microsoft repository pull request attacks, and a couple other ones that are disclosed, will hopefully drop on the twenty—what is that, Tuesday? That's going to be the… that's the 26th. So, it should be airing on the Praetorian blog then. So, if you—Corey: Excellent. It should be out by the time this is published, so we will, of course, put a link to that in the [show notes 00:32:01]. Thank you so much for taking the time to speak with me today. I appreciate it.Adnan: Likewise. Thank you so much, Corey.Corey: Adnan Khan, lead security engineer at Praetorian. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that's probably going to be because your podcast platform of choice is somehow GitHub Actions.Adnan: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Supply chain has been a hot topic for a few years now, but so many things we need to do for a secure supply chain aren't new at all. We'll cover SBOMs, vuln management, and putting together a secure pipeline. Segment resources: https://www.solarwinds.com/assets/solarwinds/swresources/whitepaper/2111swiwhitepaper_nextgenbuild.pdf https://next.redhat.com/project/tekton-chains/ https://tekton.dev/ In the news, a stroll back through the Apache Struts breach of Equifax, CISA's list of Known Exploited Vulnerabilities, Rust's replacement for OpenSSL, Go no longer throws programmers for a loop, complexity vs. design (that leads to better security), and more! Visit https://securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/secweekly Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/asw-256