“Trying to achieve security is something of a design attitude—where at every level in your system design, you are thinking about the possible things that can go wrong,
the ways the system can be influenced, and what circuit-breakers you might have in place in case something unforeseen happens,” said Mickens. “That seems like a vague answer because it is: There isn’t a magic way to do it.” Designers, Mickens continued, might even need to consider the political or ethical mindset of the people using their system.
“There’s no simple way to figure out if our system is going to be used ethically or not, because ethics itself is very poorly defined. And when we think about security, we need to have a similarly broad attitude, saying that there are fundamental questions which are ambiguous, and which have no clean answer—‘What is security and how do I make my product secure?’ As a result, we need to be more imaginative than we are right now.”
Thus, suggested Zittrain, the question has moved to the supply side: Consumers want safe products, and the onus is on designers to provide them. This, he said, opens an even thornier question: Does there need to be a regulatory board for people producing code, and if not, “What would incent the suppliers to worry about systematic risks that might not even be traced back to them?”
How to Make DevOps Work with SAFe and On-Premise Software
The main issues we dealt with in speeding up our delivery from a DevOps perspective were: testing (unit and integration), pipeline security check, licensing (open source and other), builds, static code analysis, and deployment of the current release version. For some of these problems we had the tools, for some, we didn’t and we had to integrate new tools. Another issue was the lack of general visibility into the pipeline.
We were unable to get a glimpse of what our DevOps status was, at any given moment. This was because we were using many tools for different purposes and there was no consolidated place where someone could take a look and see the complete status for a particular component or the broader project. Having distributed teams is always challenging getting them to come to the same understanding and visibility for the development status.
We implemented a tool to enable a standard visibility into how each team was doing and how the SAFe train(s) were doing in general. This tool provided us with a good overview of the pipeline health. The QA department has been working as the key-holder of the releases. Its responsibility is to check the releases against all bugs and not allow the version to be released if there are critical bugs.
No comments:
Post a Comment