Security Champion

I’ve been interested in all things related to cyber security for many years. In private I’ve played around with things like Wireshark and Burp Suite, explored a few CTF’s, and taken various courses from among other sources, Pluralsight and Cybrary (I’ve even contributed some written material as a paid training assistant for the latter). I’ve also been listening to security-related podcasts on and off for years (“Risky Business” anyone?), and tried to keep up with at least the biggest headlines in the field. For whatever reason though, I’ve never really worked with security in my professional career – at least not beyond dealing with a few things like security certificates and basic authentication and authorization solutions while coding.

A few weeks ago I was given the role of “Security Champion” for the team I’m currently working on, which means I’ll have an excuse for a little extra responsibility for making sure the teams maintains a good security posture.

So what does that mean? Well, it means I get to spend some time thinking not only about how we can make our products more secure, but also about how we can be prepared in case something does go wrong. Hopefully I will get to work on everything from threat modelling and pen-testing up to planning for disaster recovery, and fiddle around with a couple of interesting tools and frameworks along the way. I’ve consumed a substantial amount of theory about security of the last few years, so it will be nice if I can actually apply some of it in my daily work.

I’m really looking forward to this, and I hope I can find the time and inspiration to write a little more about it here as I go along.

We’ll see how it goes…


A customized shortcuts scheme for an improved debugging workflow in Visual Studio

Update: I just realized I’d forgotten one of my favorite shortcuts: Alt + N. So what does it do? See the list below! Suffice it to say, after using it I no longer worry about getting lost in tangent code while debugging. 😉

I love a good shortcut. I love it when I can perform a task without removing my hands from their regular location on the keyboard, and without having to look down to find that one special hard-to-reach key. Now as every moderately experienced programmer knows, debugging is often an essential part of the job. In fact it can sometimes take up the clear majority of your time for extended periods. That’s why I’ve always found it so strange that the shortcuts for regular debugging actions such as step over, step into, step out of and so on have such (in my opinion at least) impractical shortcuts.

The following is a scheme of key bindings that I have been using for two or three months now, and which I find natural and easy. The effect of this change has been bigger than I had anticipated: Since I no longer need to pause to look down at the keyboard while stretching for the F11 key for example, my train of thought is slightly less prone to being interrupted. Cutting out these minimal context switches means I can focus better on the code, which means I work faster and spend less mental energy keeping track of where I am, and what is going on — and there’s your improved debugging workflow.

(*) shift + F11 is a common shortcut for “step into”.


These are the main shortcuts I’ve added. Some are inspired by the use of Vim (J moves the cursor to the next line in Vim – her it steps to the next line of code), while others are based on mnemonics (G for “Go” to either start or continue debugging, S for “Stop“), etc.

Continue reading

Git bash: Clear screen and show diff

I just added another little convenience command for Git Bash. This is for clearing the screen and showing the diff (changes) in your branch. I added support for a parameter so you can use it either to show all differences, show the changes for a specific file, or append some other parameter to it (see the examples below).

Here`s the code itself – append it to your .bash_profile file, then restart your git bash:

    if [ "$1" ]; then
        git diff "${1}"
        git diff

Examples of usage:

cdiff # Will clear screen and show all changes not added

cdiff --cached # Will clear screen and show changes in added files

cdiff # Wil clear and show changes for the specified file

cdiff --name-only # Will clear, then list all changed files (not added)

“Operation could destabilize the runtime” caused by dynamic invoke.

Dynamically invoking code can sometimes mask errors that actually are pretty simple to fix. If you come across problems like this, it’s probably a good idea to try to reproduce the problem as close to the calling code as possible, in order to see the actual error message, instead of something generic like the title of this post.

Continue reading