3 possible ways to code that :
1) The SW compares each digit press on the fly (wrong implementation, security wise)
2) the SW stores the sequence in RAM, then, on the last digit pressed, compares the whole sequence to the cleartext password
3) the SW stores the sequence in RAM, then, on the last digit pressed, hashes it, then compares the whole sequence to the hash of the password. The hash should also include a salt that varies for each safe, and should not be stored in the eeprom.
The right way to implement is the no. 3.
This resists even if you could read out the data on the SPI eeprom (which is perhaps feasible, but not with the 8 bit A/D of a scope)
The way no. 2 can be broken if the compare function is not constant time. But the measurement time base must be precise to a uC cycle
The way no.1 is easy to break.
The peaks in the waveforms you show seem to be waking up cycles, or periodic interrups of the micro. Probably only one "interrupt" every two can take key presses, so you see differences based on which of those two inteerups you hit with your button press. It could be more consistent if the button presses are simulated by HW always at the same time to hit the same "interrupt"
The height of the negative peaks probably shows the execution time of the function.