How to manage security for spring boot apps?

[reddragdiva]

Dear Lazyweb! How do you manage keeping spring boot applications up to date?

We run an arseload of Java webapps. Our devs have taken a strong liking to spring boot, where everything including the Tomcat is uploaded as a JAR. A delight for them, but somewhat of a concern for the sysadmins who are the people first dealing with security issues.

So I've been asked to come up with recommendations to deal with this, and I haven't a clue as to how to do this other than laborious iterative checking, or automated versions thereof. Nor can I find recommendations.

Has anyone else got this problem or one like it? (Where applications are uploaded as a package that then runs.) What do you do?

Comments

[bob]

"A delight for them, but somewhat of a concern for the sysadmins who are the people first dealing with security issues."

fix this issue.

[reddragdiva]

it turns out these issues are difficult to patch in git.

I fear I may just end up with sufficient documentation that shows "we told you so."

[reddragdiva]

It turns out we got someone do a demo of something that does the automated version of laborious iterative checking. At a swingeing price tag, so we didn't cough up. So that appears to be ahh industry standard.

So, next trick: get buy-in!

[bob]

was it snyk?

[reddragdiva]

Dunno, apparently I was on holiday at the time. But that looks plausible.

[bob]

so containers have the same problem. you dont actually know what is being used and deployed with out some tooling around that.

one solution is the build pipeline makes new artifacts with all dependencies every $timeperiod then runs tests and deploys.

[reddragdiva]

yes, it's the broader problem of being devopsy agile, otherwise known as "who can I externalise my costs onto".

[bob]

the blockchain?

[reddragdiva]

BRILLIANT!!

no wait

[pndc]

$TATBAZAAR has a crack security team who make HMRC look cheerful, and who externalise their lack of being gruntled onto whichever department has drunk the DevOps Kool-Aid and is pretending security doesn't exist. I would find this utterly hilarious to watch if I hadn't myself been seconded onto the front line to unbugger the target of their ire before they get really upset. (I assume there are financial penalties in internal funny money, but that is way above my pay grade.)

Have you tried breaking fingers? Developers can't produce insecure crap if they can't type.

[ewx]

We have a similarly-shaped problem, of multiple external components integrated into single products, with the variation that rather than deployed by us they are sold to customers, sometimes as software packages and sometimes buried in our own hardware.

The current strategy is manual: from the bottom up, one person tracks issues in external components used in the products, and from the top down, issues in high-profile external components get analyzed for their impact on our products. The latter part seems to be working well but only applies to widely used components; the former part is dependent on our ability to match expertise and attention to particular products.

Updates are expensive both us and our customers (they're friendly about it on the phone to engineers but I gather that sales/PM staff get massive earfuls over it) so the human analysis phase isn't going away in favor of 'always update'.

There is a move to de-integrate certain components in certain contexts, so that customer supplies and updates them instead, but that hasn't happened yet and present and future development strategies will pull in more things than will ever be de-integrated.

i.e. the scale of the problem is going to grow rapidly for us and so I'm interested in any practical answers anyone has l-)