Make Your Code Safe With DevSecOps

[@POINTS2]

Well said about security. Too often, security is pushed off until the tail end of a project. As you mentioned, projects tend to get someone from outside the group to act as gatekeepers just like QA. Outsiders have little insight and tend to not add much value. This also breeds a culture of a security group at a company which specializes in only "assisting" other projects much like a consultant. A part-time security person is good to have on the team providing just what you said, doing some work and providing guidance so that others can code with security in mind. Having everyone working on the project involved with the process helps to streamline things. The assembly line model just doesn't work for software. As you put very well, there is no sprinkling of magic security dust after software has been developed!

[@urbanofreitas]

Good subject once again! Well explored. Thanks. In the future I would like to see you go deeper. Things like define security tests, plan them. How to define what to test, aiming the short feedback logic/goal of CI run, etc.

[@Absquatulationist]

Yes, more in-depth talks would be appreciated. 👍🏻

[@nowanilfideme2]

Dave, totally off topic, can you link a gallery or something of your favorite shirts & where to get them? :P

[@ContinuousDelivery]

I get most of them from qwertee.com

[@Kitsune_Dev]

Can you talk about Conventional Commits and Semantic Versioning? I really want to standardize my workflow

[@ContinuousDelivery]

In general my advice is to use simple unique ID versioning, and then if you need it, layer semantic versioning on top as a kind of "display name" for the version. I generally prefer to use an ID generated by a version control system as the unique ID of a release candidate.

[@0thLaw]

Hi Dave, will this be included in an updated edition of your book? It sure seems weird to leave out if you had such explicit steps in the pipeline.

[@ContinuousDelivery]

It is covered to some degree in the "CD Pipelines" book, but there are no plans for an update to "Continuous Delivery".

[@adambickford8720]

"We're almost ready for 1.0, just need to add tests and security". --Every death march project ever

[@brahmcdude685]

what about performance testing in CD?

[@ContinuousDelivery]

Try this: kzbin.info/www/bejne/bZzSdpZunr1qd68

[@pascalmartin1891]

It seems to me that CD here is not the _sufficient_ solution to security. Because CD is based on systematic automation, it does guarantee consistency. There is an obvious value in starting early, but a full security test suite may (will) take time to adjust to new application code. To claim that all can happen on a day cycle looks like a fallacy: add a new feature, run the test suite, sleep well? What about the new security surface created that is not yet tested? The risk is overconfidence that old test guarantee against new holes..There is a window when the system can be (falsely) declared release-ready simply because the tests are not. To blindly trust a CD pipeline status looks like recipe for disaster. There is a need to assess readiness from multiple viewpoints, to verify that the CD status is meaningful. This is typically called a gate.

[@ContinuousDelivery]

Do you think security is different in this respect to any other behaviour of the system? It is not that I expect everyone to get things perfectly right at the start, but that instead of building things that you then gate-keep later, you build your assumptions, the same ones you check in your gatekeeping, into automated evaluations of the system. Of course, this means that you need to find ways that make automating those assumptions easy, but the saving is that once they are automated you don't need to repeat them with every gate-keeping event. So this scales really very well. Naturally we may miss things, but so will the gatekeeping, so in both cases when we find the mistake we add something to prevent it in future, in the gatekeeping world, that means ever more time and effort, in the automated world it means, maybe some more capacity to run the tests.

[@pascalmartin1891]

@@ContinuousDelivery security is different because there is active malice on the attack side. Security testing is much more difficult. See all the issues with CPU branch prediction.

[@pascalmartin1891]

@@ContinuousDelivery I agree that you can generate decent security tests by trying all known vulnerabilities to every interface and parameter. Doing it this way probably make the tested software more secure than most. Doing more is way above my level anyway. When it gets more difficult is when a new type of vulnerability is discovered: then all the existing tests must be updated, even if the application software itself never changed. So you have to monitor newly discovered vulnerabilities, even in applications not related to yours. That is unusual, and I am not sure how CD helps with this. It is not like _not_ using CD would help either. I am just uncomfortable with the sales message that CD is _the_ one and only solution to _all_ software issues.

[@ContinuousDelivery]

@@pascalmartin1891 ...or just add an additional test that covers the new case.

[@kamertonaudiophileplayer847]

A rule of the thumb: do not use open source unless you're a contributor. Generally I do even smarter, I just fork a project, then inspect the content thoroughly, and if I see it is a good written with keeping a security and smartness in mind, then I start using it.

[@kamertonaudiophileplayer847]

@SuperWhisk A close source stack is a different discussion. Certainly, not many companies can afford develop entire tech stack on their own. Apple, Google, probably few more. Yes, benefits are great, but costly. Certainly not many can take the risk. I am lucky having all JavaScript code on my own.

[@AleksandarIvanov69]

why explore it by hand ? run a pipeline with a few popular security, quality and legality tools, and be done with it :)

[@kamertonaudiophileplayer847]

@@AleksandarIvanov69 Do not give hackers the clue - do not use hacks based on "popular security, quality and legality tools" caught ones.

[@kamertonaudiophileplayer847]

@SuperWhisk I work a lot with fintech companies, they won't accept your claim. But if you develop a game or other entertainment app, why do not use OSS? I am with you.

[@kamertonaudiophileplayer847]

@SuperWhisk I agree, it is an interesting topic. For example European and American institutions have different rules. But most will require escrow your code too. The worst thing you can't argue, they will select other vendor. But we can keep the discussion