Nebraska.Code() - Developing in the great plains

If there is one thing you might already know about Nebraska, it is that it is Cornhusker country. It is also home to many prominent companies like Union Pacific, Berkshire Hathaway, and Mutual of Omaha. It is also home to an outstanding developer-focused event in the great plains, bringing together developers, subject matter experts, and DevOps leads; Nebraska.Code() 2023.

Here are just a few highlights from the event.

Everyone can contribute to open source

In her opening keynote, "The Power of Open-Source: How To Contribute To and Manage Communities," Caitlin Cabrera, Engineer at Kolide, laid out her story of being a first-time contributor and shared lessons for anyone wanting to contribute.

As she shared her story, where she filed her first project pull request updating a table inside the osquery project, she also shared some principles she works toward within the project and her company, which they call "The Tenets of Honest Security."

1. The values your organization stands behind should be well-represented in your security program.
2. A positive working relationship between the end-user and the security team is incredibly valuable and worth fostering.
3. This relationship is built on a foundation of trust that is demonstrated through informed consent and transparency.
4. The security team should anticipate and expect that end-users use their company-owned devices for personal activities and design their detection capabilities with this in mind.
5. End-users are capable of making rational and informed decisions about security risks when educated and honestly motivated.

She shared there is one thing all successful projects have in common: Community! A community can only come about by creating and maintaining relationships, which makes events like Nebraska.Code() all the more vital.

According to her research, there are three main success factors that healthy open-source communities all possess:

• Collaboration and culture - A strong code of conduct and well-defined communication channels are required.
• Tech and innovation - A well-defined use case and a focus on quality are essential.
• Process and vision - Good documentation and a clear process for contribution are critical.
  

How to better get along with your coworkers

In one of the more unique but valuable sessions I have seen at any event, Arthur Doler, Culture & Community Steward at Aviture, gave us a very well-researched and creatively illustrated presentation about understanding and dealing with conflict. In his talk "How To Not Strangle Your Coworkers: Resolving Conflict with Collaboration," he defined "disagreement" as two or more people who hold differing or opposing opinions or beliefs about something. This escalates to "conflict" when the topic is seen as important to each party involved, there is an interdependence in roles, and both sides believe that the evidence is on their side.

Arthur shared the research into the three kinds of conflict:

• Task conflict - This is the most common type and deals with how to do an individual job in a process. Arthur stressed this is not necessarily bad, as it can lead to positive discussions about how to get the best outcomes from a particular task.
• Process conflict - This is most often experienced early in new projects and with new team members. Ongoing process conflict can become personal and toxic if people feel hurt or ignored.
• Relationship conflict - This is always bad and needs to be avoided at all costs. If you feel you are personally at odds with someone and feel there is a lack of trust, then it will be impossible to reach the team results you want.

At the heart of how we avoid or resolve conflict is the need for psychological safety, which he defined as the feeling it's OK to take risks and speak up when conflict arises without fear of reprisal. We are all risk-averse and want to preserve the strength of our relationships. Having the trust that you can speak your mind without negative repercussions is how healthy teams evolve.

While he gave a lot of advice on understanding your teammates, it really does come down to aligning goals for most types of conflict and recognizing that, as humans, our emotions are going to be involved. If we strive to find win-win outcomes, we can use conflict to build better teams and improve ourselves.

Understanding encryption

At the heart of most of cybersecurity is encryption. We spend a lot of time focused on the keys that lock and unlock data and access to systems. Fortunately, we don't have to spend a lot of time pondering how encryption itself can best be safely accomplished. It is still important to have some base level of understanding of cryptography as we manage our credentials. This is why I am grateful that Joel Lord, Developer Advocate at MongoDB, shared his knowledge on the subject in his talk "A Gentle Introduction To Data Encryption."

He began with a history lesson and the story of Demaratus, who hid a message to the king of Sparta underneath another message written in a layer of opaque wax. This is the mythical origin of steganography, the practice of concealing a message. This then gave rise to ciphers, or encryption by substitution, where plaintext messages are transformed into an unreadable format. This is the science we today call Cryptography.

One of the more important concepts in cryptography is hashing, transforming any set of characters into a string of fixed length. This alone does not make your message secure, but once we add a secret key to a message, hashing produces a very different output and a secure way to represent the message when communicating publicly.

He also covered the math behind and differences between AES symmetric encryption and RSA asymmetric encryption in far greater depth than we can go into here. To summarize, though, there are other ways to encrypt messages, but RSA is the basis for the most popular methods. If you use a public/private key pair, such as your SSH key, then you are likely using RSA.

Joel left us with some wise words: "Do not write your own encryption for production use." There is a lot of complex math, and unless your job is to make new cryptography tools, then you are going to spend a lot of time reinventing the wheel. It is also dangerous, and security is hard enough as it is, as we have seen from some recent events.

A QUIET and CALM approach to testing

While the main subject of his talk was performance testing, David Handlos, Senior Software Engineer at Q2, shared some very practical advice for anyone doing any kind of testing in his session "The Performance Testing Process: Before, During, & After." After years of doing performance testing, he has developed several acronyms you can use to keep on task with any kind of testing, especially testing stakeholders care about.

The first acronym for testing he shared was QUIET:

• Question - What’s our goal for testing, and when will we be done? If you can not define a "done" state, do not start or go any further.
• User Definition - Who is our “user” in the use cases during the testing?
• Inform - Inform all stakeholders involved of the performance testing that needs to happen and the impact involved.
• Environment - Assuming stakeholders approve, set up the environment for testing, if it does not already exist.
• Test - The final step; the actual test.

The main focus is defining what success means and communicating that throughout the process. This can be applied to any type of testing. Running a test successfully and passing a test might mean something different depending on which stakeholder you ask, so spend time and be clear.

The second idea he shared about ensuring good test results was to remain CALM:

• Consistent - Ensure your test results are as consistent as possible with every run.
• Automate - From running the tests to gathering the results, automate whatever you can.
• Lean - Minimal test environment, as few variables, as few external dependencies as possible.
• Metrics - Make sure the metrics being gathered are meaningful.
  

Understanding Azure Key Vault references

Consistent and proper usage of secrets managers like Azure Key Vault is half the battle when tackling secrets management maturity. That is why I was so excited to see and share "Utilizing Secrets in your C# MVC projects and Azure Services with Azure Key Vault" from Microsoft MVP Brian Gorman.

He demonstrated how easy it is to get security wrong when working on a project. He walked us through how tricky it gets setting all the security configurations just right. In a rush, it is easy to just allow for full unauthorized access to all the resources or to do something like hardcode plaintext credentials to access the DB. He also showed us how easy it is to use Key Vault in Azure to properly store, manage, and access project secrets.

While Key Vault is an excellent solution all on its own, the real power of this secrets manager is unleashed when paired with Azure App Configuration. Created as a way to deal with the challenges of application configuration in distributed environments, Azure App Configuration allows you to manage settings in the runtime environment or in a single external source. When used with Key Vault, it allows users to centralize the management of secrets for different environments and geographies dynamically without the need to redeploy or restart an application.

Brian also warned against returning plaintext credentials in log files. He showed how to create a simple log sanitizer script using RegEx to replace any reference to personal identifying information, like emails or telephone numbers and passwords. Instead of the real password being printed, the script does a quick substitution of the word " [redacted]."

Developing community in the Great Plains

GitGuardian is proud to have been part of this awesome event, as your author got to present two sessions:

• "Who Goes There? Actively Detecting Intruders With Honeytokens," where I discussed the history of cyber deception and how to employ honeytokens at scale.
  
• "Do you know where your secrets are? Exploring the problem of secret sprawl and secret management maturity," where we walked through the findings of https://www.gitguardian.com/state-of-secrets-sprawl-report-2023, the Voice of the Practitioners report and our Secrets Management Maturity Model.

There were a lot more sessions and conversations at Nebraska.Code() 2023, more than we can recount here. In all of the sessions, though, there was a sense of real community being built. While AI and ChatGPT might have been on the tip of everyone's tongue, there was a feeling that there has never been a better time to be a developer nor a better time to be part of the larger development community.