Beveiliging is belangrijk voor alle projecten, oud en nieuw. Als technische partner begeleiden en adviseren we zowel nieuwe als bestaande klanten hierin.

We proberen ons zo te houden aan niet enkel de meest gangbare best practices, waaronder de OWASP-richtlijnen, maar ook een stap verder te gaan en bijkomende voorzorgsmaatregelen te treffen. We controleren zo steeds geautomatiseerd projecten en hun afhankelijkheden op kwetsbaarheden (CVE), streven steeds naar een score van A+ op de Mozilla Security Observatory en hanteren interne maatregelen om lekken te voorkomen.

OWASP

OWASP is een gemeenschap van experts die onder meer best practices en veelvoorkomende problemen omtrent beveiliging beschrijft. Dit gaat van algemeen bekendere problemen tot complexere en niet-zo-vanzelfsprekende problemen.

OWASP heeft zo een top 10 van meestvoorkomende problemen uitgeschreven, die onze ontwikkelaars steeds in hun achterhoofd dragen bij de ontwikkeling van je project.

Automatische controles (CVE)

CVE is een databank waarin kwetsbaarheden gepubliceerd worden. Af en toe kan er zo een kwetsbaarheid gespot worden in softwarebibliotheken die we gebruiken, waarvan vervolgens een zogenaamde "CVE" gepubliceerd wordt.

Bij Inventis voorzien we automatische controles op basis van deze kwetsbaarheden, waardoor we automatisch op de hoogte gebracht worden als een dergelijk probleem opduikt, waarna we deze zo snel mogelijk kunnen rechtzetten en websites niet langdurig vatbaar blijven voor problemen waarvan we niet op de hoogte waren.

Mozilla Security Observatory

De Mozilla Security Observatory is een tool van Mozilla - de organisatie achter de browser Firefox - die websites scant en een score geeft op basis van hoe goed ze voldoen aan hun richtlijnen.

Een hoge score is geen garantie op volledig veiligheid, maar je kan hierdoor wel wat geruster slapen, gezien de hoogste scores strikte voorwaarden hebben die verschillende types kwetsbaarheid onmogelijk ofwel moeilijk maken.

Wij streven steeds naar de hoogste score van A+ voor onze projecten. Graag zouden we hiervan een belofte willen maken, maar de criteria kunnen doorheen de tijd plots veranderen. Sommige technologieën die je wil gebruiken kunnen ook incompatibel zijn hiermee. Als dat het geval is, brengen wij je proactief op de hoogte en kan je zelf beslissen of je dit risico alsnog wil nemen.

Interne maatregelen

Niet enkel tijdens de ontwikkeling houden we rekening met veiligheid, maar bij ons intern draagt iedereen hieraan bij. Enkele voorbeelden van onze maatregelen:

• We gebruiken twee- of meertrapsauthenticatie voor gevoelige accounts.
• We delen onderling geen wachtwoorden via onveilige(re) media zoals e-mail, chat of ons ticketingsysteem, maar gebruiken password managers en links die verlopen.
• We hergebruiken geen wachtwoorden, maar genereren aparte en sterke wachtwoorden per account of website (ook bij het opzetten van accounts of sleutels voor jouw website).
• We nemen geen paswoorden of andere gevoelige gegevens op in onze code, maar houden deze gescheiden in het geval je de code wil laten inzien door derden.
• We vermijden het gebruik van productiegegevens op testomgevingen door enkel testdata te gebruiken, gevoelige gegevens eerst te verwijderen, of deze zo snel mogelijk terug te verwijderen (als we deze bv. nodig hadden om een probleem na te bootsen).

Wat als mijn project een dagje ouder wordt?

De bovenstaande beloftes gelden uiteraard voor onze nieuwe projecten op het moment van schrijven (januari 2020), maar ook als we jouw ouder project nog onderhouden kan je erop rekenen dat we hier actief naar kijken. Dit kan zich vertalen in kleine verbeteringen die we zelfstandig alvast uitvoeren, of - bij ingrijpendere wijzigingen - advies van onze kant om de huidige situatie te verbeteren.