Re:VP of InfoSec at InVision on secure code development [audio]
by bionicbits on Friday March 22, 2019 @11:57AM
(#19463783)
I wonder if languages like Rust would be helpful in areas like this? Especially considering that the strictness of the compiler might allow more "green" developers opportunity to contribute.
Re:VP of InfoSec at InVision on secure code development [audio]
by tptacek on Friday March 22, 2019 @01:25PM
(#19464738)
No. Rust eliminates C/C++ memory corruption vulnerabilities, but so do all the other mainstream high-level languages.
What Rust enables you to do is ship software that formerly would have demanded C/C++ (kernels, drivers, embedded software, browsers, games) without having to use C/C++. That's a security win, but not a game changer for secure software development in general, the vast majority of which is done in non-C/C++ languages already.
Re:VP of InfoSec at InVision on secure code development [audio]
by bsamuels on Friday March 22, 2019 @12:44PM
(#19464298)
Rust addresses C/C++ security issues, but that's where the security benefits end (that's still a lot of benefits though!)
I really wish "units of measure" types took off in the langdev world. "String" is woefully inadequate to describe the actual type of a string; Imagine a world where string data is of type <string:urlencoded> or <string:xsssanitized>, and display functions would only accept strings of the correct type. I know F# has this, but unfortunately it never caught on elsewhere.
Re:VP of InfoSec at InVision on secure code development [audio]
by tptacek on Friday March 22, 2019 @01:24PM
(#19464711)
Most modern frameworks, in all the mainstream languages, already have this feature, and it's usually the default. You still get XSS because you still have to override the filter to do custom HTML, but it helps a lot.
Re:VP of InfoSec at InVision on secure code development [audio]
by spydum on Friday March 22, 2019 @12:55PM
(#19464397)
I think obviously no: language definitely contributes to SOME vulnerabilities, but it does not solve all or even most of them. java apps are great example of memory safety, type safety, and still huge vulnerabilities exist in java apps.
Re:VP of InfoSec at InVision on secure code development [audio]
by devmunchies on Friday March 22, 2019 @11:42AM
(#19463620)
> InVision is a 100% remotely distributed company. We don’t have an office, we have almost 1000 employees, we have scaled to 1000 people with everyone working out of their own home
just like most open source projects.
one of the bad parts IMO is that you can't hire green engineers since they need more hands-on guidance.
Re:VP of InfoSec at InVision on secure code development [audio]
by saidajigumi on Friday March 22, 2019 @12:21PM
(#19464059)
I've thought the same, but is this true?
A shout-out to HN folks w/ experience at full-remote companies: are there hiring and onboarding practices you've used that allow less-experienced hires to be successful when working remotely?
Re:VP of InfoSec at InVision on secure code development [audio]
by jmccarthy on Friday March 22, 2019 @01:01PM
(#19464463)
On our full-remote team the #1 onboarding (and ongoing) practice for engineers is near-full-time pair programming.
For engineers who haven't logged many pairing hours before, it requires a few weeks of stamina-building: it's initially exhausting to hold a model in your head while engaging your vocal cords.
One non-obvious but critical tip for continuous pairing: ensure everyone has an excellent audio environment. Buy the right headset, have a door or acoustic foam installed in the home office, etc.
Re:VP of InfoSec at InVision on secure code development [audio]
by Bhilai on Friday March 22, 2019 @02:18PM
(#19465320)
> A bug bounty program, you’re inviting the entire world to attack your site. And by the way, you you’re not obviously using production, right, you’re spinning up a clone that has no customer data. And it’s not even connected to your network.
> Also, pen tests rarely perform lateral movements across your app, right? .... Whereas a bug bounty, those people can continue to move and infiltrate your network and give you a string of attacks that they were able to finally polling your data,
So I may have misunderstood (or the transcribing is wrong) but the person says you should give bug bounty hunters an isolated non-production instance and yet wants "lateral movement" ? Sounds a bit incoherent.
I'd expect security is important because of the pre-release and experimental nature of most product mockups.
What Rust enables you to do is ship software that formerly would have demanded C/C++ (kernels, drivers, embedded software, browsers, games) without having to use C/C++. That's a security win, but not a game changer for secure software development in general, the vast majority of which is done in non-C/C++ languages already.
I really wish "units of measure" types took off in the langdev world. "String" is woefully inadequate to describe the actual type of a string; Imagine a world where string data is of type <string:urlencoded> or <string:xsssanitized>, and display functions would only accept strings of the correct type. I know F# has this, but unfortunately it never caught on elsewhere.
(To be clear, your latter point is referring to things like 'dangerouslySetInnerHTML' in react?)
https://reactjs.org/docs/dom-elements.html#dangerouslysetinn...
just like most open source projects.
one of the bad parts IMO is that you can't hire green engineers since they need more hands-on guidance.
A shout-out to HN folks w/ experience at full-remote companies: are there hiring and onboarding practices you've used that allow less-experienced hires to be successful when working remotely?
For engineers who haven't logged many pairing hours before, it requires a few weeks of stamina-building: it's initially exhausting to hold a model in your head while engaging your vocal cords.
One non-obvious but critical tip for continuous pairing: ensure everyone has an excellent audio environment. Buy the right headset, have a door or acoustic foam installed in the home office, etc.
> Also, pen tests rarely perform lateral movements across your app, right? .... Whereas a bug bounty, those people can continue to move and infiltrate your network and give you a string of attacks that they were able to finally polling your data,
So I may have misunderstood (or the transcribing is wrong) but the person says you should give bug bounty hunters an isolated non-production instance and yet wants "lateral movement" ? Sounds a bit incoherent.