Last Call for Sessions

Today was the final day at CodeMash. I went to several sessions, including: "Real Pirates Seek the C!", "Hardware is from Mars, Software is from Venus", "Autonomous Microservices", and "Building an AppSec Program". I also jumped in a session where they discussed agile practices.

I'm going to make some quick notes about what I learned and what I found to be surprising.

Real Pirates Seek the C!, presented by Clay Dowling:

C is probably best known as a procedural language but it supports functional and object oriented programming. It's a language that seems to have a very close relationship to the operating system. Consequently, some concepts you'd have to consider include memory allotment and default state.

Some surprising things about C:

1. Unlike some other languages, such as JavaScript, you can't pick it up in an hour and get an app up and running. However, C doesn't need much to get started besides the terminal and an editor. It's a small language with fewer options.
2. It does not come with a build system. I guess I've been spoiled with JavaScript, but for C you need to find a compiler.

Hardware is from Mars, Software is from Venus, presented by Kimberly Clavin and Clay Dowling:

In the industry, software and hardware teams should work together, but, more often than not, they don't. To start the session, Kimberly and Clay asked the audience: You are starting a project...should it be software driven or hardware driven? They followed up by asking which was more important between performance, agility, and cost. It's interesting to consider which side leads the project by default, which ends up receiving more lead time, and why unplanned costs occur. Rather, the challenge is how these two sides communicate with each other initially and as requirements change. Cross communication needs to happen early and often. A lack of communication will lead to higher costs (either manufacturing or development costs). Given the complexities of issues and knowledge gaps across teams (all of which will impact the work of each area), at the very least, I would recommend that there be an advocate that has knowledge of both domains that can advocate for each area and help these teams work together. This advocate would have to value knowledge sharing and communication. I think this would prevent conflict and manage costs associated with timeframes and knowledge gaps. However, Kimberly and Clay concluded that projects should be systems driven, not hardware or software driven. A systems driven process calls for design and iteration integration across both domains.

Some surprising things about the relationship between hardware and software:

1. Software and hardware teams typically aren't knowledgeable about each other's domain. There are issues and specific lingo in each domain that needs to be shared across these teams.
2. One team's cost saving could mean higher costs for the other team. However these complexities are not usually resolved early on as a whole, but rather in each separate territory.

Autonomous Microservices: This session was sponsored and presented by Couchbase.

A monolith system functions as a single autonomous unit. When the application needs to be scaled or when some functions need to be modified, the entire application needs to be rebuilt. A microservice architecture is a solution for scaling and maintaining application functions with ease. Instead of a monolith system, modular units make up a system. These units are microservices. They can be written in different languages or use different database storage techniques. The system is more flexible in terms of scalability and deployment. Matthew Groves from Couchbase described some principles to deal with distributed systems, asynchronous communication, and databases.

Some surprising things about microservices:

1. Each service has its own database. Scaling with relational databases becomes expensive and at some point scaling is no longer possible.
2. Deployment requires using a distributed systems environment such as Kubernetes.

Building an AppSec Program from the Ground -- An Honest Retrospective, presented by John Melton:

In this session, John shared his experience building an AppSec program from scratch. He discussed his proposed quarterly deliverables, results, and lessons learned. He joined an acquired startup where there were no people that purely focused on security. His tasks included updating HR and tech training programs, addressing security gaps, and preparing the team for compliance. He approached his journey by embedding himself in the culture and environment. During his first quarter, he took time to learn about the team and its existing tools and processes. He made a point about not coming into a new place and suggesting changes right away, but instead investing time in learning about the environment. He also completed static, dynamic, and dependency analysis. He said that starting with metrics was important especially when you're in an environment where your recommended processes are not currently in place. He took application inventory to show deployment states, testing history, and server information. After evaluating the lack of processes and cleaning up credential storage, he focused on updating the SDLC, completing threat modeling-sessions, and tracking attack surface. Throughout his journey, he found value in forming relationships with key stakeholders, making security part of the developer culture instead of something seen as needing to be separately integrated, and developing methods to rank and communicate vulnerabilities.

Some surprising things about his journey:

1. When John first joined the team, the developers saw him as "the bad guy". The people were antagonistic towards him. He was brought on to secure applications, but he didn't feel like the team that he was working with actually wanted him to add value or address deficiencies. They kept him at arms length. To resolve this, he stayed humble and dedicated time to connect with the team and with the tribal knowledge owners.
2. He realized that more people approached security by addressing things that were wrong. However, he was interested in proactive controls. These types of controls would embed security more naturally.
3. He found help for tools and processes by connecting with people at conferences such as CodeMash.

Overall

The staff did a great job hosting the multifaceted conference. There was a robust selection of session topics geared towards various skill levels and interests. The sponsors and staff were all welcoming and passionate about software. I'm excited about next year's conference!