Stay up-to-date with my words ✍️

Over September 11-12, I was fortunate to attend SBOM-a-rama, a critically important conference hosted by CISA, America’s Cyber Defense Agency. CISA exists to mitigate risks in the cyberspace ecosystem and manage critical infrastructure of the United States, but represents just one sector of many that are molding and evolving the future of cybersecurity globally.

## Day 1

With speakers and participants from multiple countries and many industries, including \~ but not limited to \~ government, healthcare, software development, and supply-chain security. The agenda for the day was strategically set to maximize presentations while permitting time for questions and discussion. As the ballroom fills, the excitement is palpable as people connect with long-distance coworkers and colleagues, some of whom they communicate with weekly but are just now meeting in the flesh. Participants take their seats and at 9am sharp the convention begins. Across technical and legal divides, there is a unitary, glimmering goal of industry wide collaboration. Specifically, there is a call to action from many for global data normalization, standardization of naming conventions and component identification. The working goal is to reach a single SBOM approach that is compatible with distinct and extensible use cases.

This is where the solidarity fractures. Specifically, to what extent is disclosure necessary in order to secure vulnerabilities and enhance technological trust and transparency? Documentation outlining the minimum requirements for a Software Bill of Materials (SBOM) exists, but as experts from across the globe exchange views on the current problems in cybersecurity, it is evident that these regulations require further deliberation. There is a consensus from many that sharing data is the way forward. But this solution presents complications in data ownership, legal sovereignty, and the real world implications of a global data lake, from storage to privacy and protection.

As the discussion progresses it is apparent that there must be a proprietary distinction between internally shared SBOM data and readily available SBOM data. Interconnectivity between security and development teams is a must, so how do we foster communication flow inside and outside of an organization?

### Day 2

Beyond the future of SBOM generation, vulnerability tracking, and risk management sits a team whose goal is to determine a standard for transparency and trust in AI models. Of the many Tiger Teams that tackle various issues, the AIBOM team may have the largest challenge. In a field as largely unregulated as Artificial Intelligence, standards for trust and transparency are critically important. But what can &/or should be disclosed? 

In between the hustle and bustle of the tech solutions showcase, the AIBOM team gathers with other brilliant minds in cybersecurity and software development to discuss and debate the standards for transparency. While most support the inclusion of training data and model weights in this proposed AI Bill of Materials, experts point out that it can take years to refine the model weights and that level of detail should not be open source or available. 



Reflecting On SBOM-a-rama 2024

My experience in ASU's FullStack Development bootcamp has rewired the way I code, and entrenched my love of learning. I will never know everything; rather, I can learn *anything.* This blog post does not seek to teach coding principles, but to share a few brief examples of the things I learned that are shaping me.

##### Finding a style: Experimenting with Workflows

Coming from coding as a hobby, my workflow was scattered and dependent upon my level of interest in the project; I could spend 5-10 hours a week, or invest 60 hours in 4 days. There are zillions of workflows for every brain, but I found consistency and success working with agile methodologies. With an iterative approach, I could be responsive to unexpected changes instead of frustrated. Branching off main to experiment with alternate options and new features saves the hurt of breaking working code. I am a perfectionist, so focusing on generating a MVP (minimum viable product) for each project allowed me to use excess time to add my stretch goals. By prioritizing the user & interactions over processes & tools, the processes or logic came naturally.

Well not entirely natural - there was a lot of drawing diagrams and flows, daydreaming of the final product, and thinking through each step from file organization to integrating APIs and more. In my workflow, each file starts with comments of *what* I am trying to do. As I code, when I think of other features or functionality I would like to add I update my kanban board for the project on GitHub. With columns for every stage of development, it is easy to keep track of how much needs to be done.

##### Conceptualizing Goals

By thinking through the logic needed to accomplish said goal, I am priming my brain with the concepts needed to code in any language. Just as humans across the globe speak a multitude of languages to convey the human experience, the meaning matters more than the exact syntax or dialect in which one speaks it. By deepening my understanding of programming concepts, I am better prepared to code in any language. Regardless of the syntax, concepts and best practices apply.

Of all the best practices taught, the one I repeatedly use everyday happens to be **DRY**: Do Not Repeat Yourself. Functions are intended to execute one specific *function,* so it follows that the code to execute that specific task only needs to appear once. When working with React or other languages/libraries, code reusability saves time, space, and creates a seamless template for rending any kind of data. As my professor taught us, if you have to type the function twice in the project, could it be imported? Additionally, ternary operators and ways of condensing logic from long, drawn out if...else and switch case statements help keep code clean and concise.

##### Team Communication

With 3 group projects across the 24 weeks of bootcamp, I learned rapidly that communication isn't just important - it will save you hours. From the first group project where tension built up because no one understood each other or their code, to the last where we reached our MVP in 3 days, the night and day difference is a direct product of better group communication. By establishing a communication flow in a groupchat on Slack and repeatedly updating the team on my work, the rest of the team joined in and contributed updates, questions, and resources. As a result, we avoided working on the same features, solved bugs much faster, and were able to go for our stretch goals with 10 days left until the project deadline.

Overall, I am grateful for this opportunity and developing the ability to *read* code, rather than just assemble it.


The Future of Secure Web Development

Reflecting On SBOM-a-rama 2024

Bootcamp Takeaways