 Now, let's hear from Kevin Gilpin how AppLand provides innovation to better visualize your code structure. As I said, this could be quite handy in conjunction with S-bombs that we discussed earlier, but could also be a collaboration tool to help Dev and Sec get on the same page. From AppLand, I'm here today to talk about how we build our understanding of code, how we share that knowledge with other people, and how to use new tools for guidance and navigation as we create, fix, and improve code. When we make structural changes to code that affect how things work and fit together, it's important to just pause for a minute and confirm our assumptions before we start changing things. Getting extra context, getting it oriented is important when making performance changes, refactoring, or fixing tough bugs because the actual behavior of code becomes less apparent when making these types of complex changes. Helping people collaborate and better communicate in order to build good software is my favorite kind of problem to work on. And this is particularly relevant in DevSecOps because security has specific skill sets and values. Bringing Sec into DevSecOps requires everyone to learn more about people and adjacent roles and learn a bit of their language and value system in order to collaborate and share context efficiently. I love making tools that help people who are doing different jobs to work together, and I've been working to bring developers, security, and operators closer together since 2012. To get specific about communicating about code, I'll step into an example which comes up all the time in practical development work. It's a basic communication process that happens every day between three different people in different roles. The first person in my example is someone who's reporting a bug. It could be another developer, a QA tester, or a security tester. It's someone who sees improper app behavior and wants to report the problem. The second person is the developer who fixes the problem, and the third person is the code reviewer. So there are two handoff stages from the bug finder to the developer and from the coder to the code reviewer. At each stage there's a need for knowledge transfer between people who have a very different level of experience with the code in question. In fact, it's possible that none of these people really know this particular area of the code very well. But they all need to work together to get a code change written, reviewed, and approved. The bug finder knows that the dev team wants as much descriptive information about the bug as they can get. What the tester was doing, what they typed in, what buttons they pushed, what they saw. This description can be accompanied by some screenshots. For UI bugs, this works great. Screenshots usually make it evident what went wrong. But what about bugs in application behavior, where it's backend that's misbehaving? Maybe the user is presented with inaccurate information or data belonging to someone else, or they expect to go to one page but end up on another. So what then? As a developer, wouldn't it be helpful if the bug finder could send along the equivalent of a screenshot but of the backend internals? How about a map of code paths including all the dynamic and complex stuff, like HTTP requests, caching, the user, session, security, and SQL? This is the code map concept. And when I say code map, I mean some kind of visual presentation of the code other than the code as text that makes a design aspect of the code easier to understand. Making code maps is possible with an open source tool called app map, which makes runtime recordings of code. It works equally well on large and small projects, web applications, and microservices. It captures all the information I described above and bundles it into a portable JSON format. It's easy to write programs that process, analyze, and display the data. The code maps are an effective way to transfer information about bugs from testers to developers and then to code reviewers. So let me show you an example of how it works. This is the Rails sample app, which is a Twitter clone. Even when you're not logged in, you can see the feed of any user. Right now I'm logged in as example user and I'm following users like user19. I can go visit user19's own page. If I log out and put that URL back in the address bar, I can still see it. I'm going to report this as a bug and request that login be required to see any user page to prevent the data from being scraped by malicious actors or anonymous bots. So I'll start by opening this new issue, require login to view user. We've talked about code maps and how they can help developers, so I'll enhance this issue by adding app maps and I can make them by recording the app while I use it. I'll start by turning on app map recording using the app map browser extension, reload the page to activate the behavior I want to fix, and then go back here to stop recording. When I stop it, an app map is created and uploaded to app map cloud. If I don't want to use app map cloud, I can record app maps using the app map extension for VS Code or JetBrains and keep everything locally. So I'll add the link to this app map to my bug report. Notice that I don't need to know much at all about Rails or how the solution to this problem will be implemented. I'm just recording some relevant aspects of the app, what I was doing and sending them to the developer. So adding an app map is like including a screenshot, but for the back end, I'm intentionally not digging into what's in the app maps because as a bug finder, I don't really need to know. I've learned from developers that this information is helpful to them. Now, I will switch roles and become the developer who's working on this issue. So I'm in VS Code with the app map extension for VS Code, and I've pulled down this app map user page not logged in into my code editor. And I'll be using this app map to implement my solution. Each app map shows a specific end to end code and data flow. In this case, this one URL request. So everything I see and all the relationships are relevant to the bug, and it opens to a dependency map, which is our first code map. So from this app map, as I mentioned, I can see that the URL route is get a user page. And that way I know exactly where the user was when they were using the app, and so creating a test case will be easy. I can also see that the page was not redirected, it was rendered by this 200 status code. Furthermore, I can see that the page was handled by this user's controller. So that is probably where the login check will need to be implemented, and I can open the source code of user's controller easily. If I want to, I can see any function like user's controller show in the trace view. I can see the function call in context of the call tree. I can see also things like SQL. And so this trace view is our second code map. So now that I've seen how the app is behaving now, I need to figure out how I'm going to implement the fix. So here in this application, this repo has an architecture.md document. The purpose of this document is to lay out some high level concepts of the architecture. So here's a section on login and session management. Requires a login user. So requiring a login user is enforced by a before action and it's labeled security.requireLogin. This is a link to an app map that I can open up to get the details about that. I will search for security.requireLogin. And with that, I can jump right to the logged in helper function, which unless the user's logged in, it will store their location, set a flash message, and then redirect to the login URL. That method is as promised in a before action. So now I can go over to my user's controller, look for the before action, and I can see that logged in users applied to a bunch of different methods, but not to show. So I'll add that there. Now I can go back to the user interface, reload this page after the code change, and I'll be redirected to the login screen. So that's a good indication that I'm on the right track. The next thing I need to do is run and update the tests. And since I've changed the behavior of a controller, I can expect there may be a test failure here. I'm running the test using this command bundle exact rate app map, which runs just, it's a smart command that runs just the test cases that need to be run in response to the code changes that I've made. And I can see that in fact this test expected a 200 response from an anonymous user visiting a user page, and that's no longer the behavior. So I'll change that to a redirect. And I'll also add another test here where I'll log in as the user first and then I should see the 200 status and the appropriate data. So I can come back down here to my break app map command and rerun the tests again. This time everything should pass. When I update the app maps, a swagger description of the web services is automatically updated. So up here in my diff view, I see the change to the test. I see the change to the controller. But I also see this open API underscore stable, which is a swagger file. And if you're not familiar with it, swagger is another type of code map, the third one in this example. It's a concise but complete description of web services and it makes it obvious what's changed in the web services. So I'll commit this file. And when the reviewer comes, they'll see the new 302 status code added to the user page. So swagger diff gives the reviewer a ton of information about what the new code does. And because the swagger is generated, not written, it always represents the real behavior of the app because it's recorded from code, from code runtime and execution. So with all this context, the swagger diff, the visual diff, the app maps, the reviewer will have a lot of information about the code change and it will be easy for them to review the change, hit the approve button and merge this code. So that's a quick tour of using code maps to accelerate code understanding and improve communication. If you want to try this yourself, you'll install app map for VS code or JetBrains. You'll install and configure the app map client agent for Ruby Python or Java. Follow a quick start guide to create app maps and then commit and push your config changes so that everyone on your team can make app maps for the repo. If you want more information, check out these links and all the client code for app map including language agents and code editor extensions is all open source MIT license. Thanks for watching the talk and I'm looking forward to your comments and questions.